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3 ELECTRONIC BILL PRESENTMENT SYSTEM WITH CLIENT SPECIFIC 

4 FORMATTING OF DATA 

5 

6 BACKGROUND OF THE INVENTION 

7 1 . The present invention relates to a financial transaction system and method, and 

8 more particularly, to a network-based system and method for billing and 

9 payment. 

10 2. Recently, there has been an increase in the popularity of performing financial 

11 transactions using the Internet as a centralized network for linking the individual 

12 financial systems of a plurality of entities transacting business with one another. 

13 With the recent explosion in e-commerce, the increasing acceptance of the 

14 Internet as a less expensive and more efficient way of doing business, and the 

15 advent of new server technology and sophisticated online security systems, 

16 Internet-based financial transactions are becoming ever more common. 

17 Advantageously, an Internet-based financial transaction system for bill 

18 presentment and payment may reduce many of the transaction costs 

19 associated with other financial transaction systems, such as preparation costs, 

20 banking fees, and costs for clearing, reconciling and closing. Moreover, such a 

21 transaction system may seamlessly handle transactions from virtually any entity 

22 with Internet access, regardless of the nature of the business, geographic 

23 location, size, or trading currency, even those entities for which the costs of 

24 traditional invoicing, presentment and payment have traditionally been high. 

25 3. Traditionally, invoice presentment and bill payment procedures have required a 

26 capital outlay for the equipment to prepare and distribute each invoice, as well 

27 as collect and reconcile payment of the invoice. Additionally, there are costs 

28 and collection delays associated with the multiple steps required between 

29 multiple parties to effect invoice presentment and bill payment. Such steps may 

30 include the payee's preparation and distribution of invoices by mail (which may 

31 take up to a week to reach payers) or electronically; one or more invoice 



1 approvals by individuals or departments within the payer's organization (e.g. a 

2 purchasing manager); invoice adjustment or dispute by other individuals or 

3 departments; payment authorizations by other individuals or departments; 

4 payment issuance, either electronically or by issuance of a paper instrument, 

5 such as a check, (again, typically by mail); receipt of payment at the payee's 

6 side, either by the payee, the payee's bank, a lockbox, or other payment receipt 

7 entity; and processing of the payment either at the payee's bank, at the payee's 

8 accounts receivable, or both. This entire process may take several weeks, and 

9 requires separate accounting records to be kept and harmonized at both the 

10 payer's (accounts payable) and payee's (accounts receivable) sides, and/or 

11 within other decentralized record keeping systems. 

12 4. There are further costs and collection delays associated with any adjustments 

13 to the invoice that may be made by either the payer or the payee. When an 

14 adjustment is made within one record keeping system, the adjustment must be 

15 communicated to the other system(s) so that a corresponding adjustment can 

16 be made. For example, an invoice adjustment made by the payer results in the 

17 payer's entry of an adjusted invoice amount into its accounts payable, as well 

18 as the payer's mailing a copy of a manually-adjusted invoice to the payee, so 

19 that the payee can update its accounts receivable. 

20 

21 SUMMARY OF THE INVENTION 

22 5. A first aspect of the present invention is to provide an electronic bill 

23 presentment and payment system. The system comprises a billing database 

24 for storing billing data related to a plurality of bills. Each bill represents an 

25 amount payable to a billing client from a paying client. An application server 

26 receives a plurality of instruction files, each representing a transaction for 

27 reading and manipulating billing data, performs the transaction utilizing data 

28 included in the instruction file, and provides a data response file complying with 

29 a predetermined format. A presentation server is coupled to the application 

30 server and includes a document database comprising a plurality of document 
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1 style sheets. Each style sheet represents a format for the response data in a 

2 predetermined document format corresponding to one of the clients. The 

3 presentation server receives the response file and generates a client document 

4 utilizing data extracted from the response file and the document style sheet 

5 corresponding to the client. More specifically, the style sheet utilized by the 

6 presentation server may be a style sheet associated with the billing client 

7 associated with the transaction. 

8 6. The document style sheet may include a plurality of document fields and the 

9 presentation server may populate each document field by matching data from 

10 the data response file to populate the document field. More specifically, the 

1 1 data response file may comprise a plurality of data fields and a plurality of 

12 predetermined tags, each tag identifying one of the plurality of data fields and 

13 the presentation server may utilize a tag to identify data for inclusion in the 

14 client document. Further, one of the predetermined tags may identify a data 

15 field which identifies the billing client associated with the transaction and the 

16 presentation server may utilizes the data field which identifies the billing client to 

17 select a document format for presenting the response data to the client. 

18 7. The data response file comprises an XML message and the client document 

19 may be an HTML document. 

20 8. In another aspect of the present invention, the presentation server may further 

21 receive transaction request files from each of the biller clients and payor clients 

22 and generate the instruction file in response thereto. The transaction request 

23 files from each of the biller clients and the payor clients may be HTTP posts and 

24 the instruction file may be an XML message. 

25 9. Yet another aspect of the present invention is to provide a method of providing 

26 electronic bill presentment and payment services to a plurality of billing clients 

27 and a plurality of paying clients. The method comprises receiving an invoice file 

28 from each of the plurality of billing clients and populating a billing database with 

29 data from each invoice file. The invoice file representing amounts payable to 

30 the billing client from at least one paying client. The method further comprises 
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1 receiving an instruction file from a client representing a transaction for reading 

2 or manipulating data in the billing database, performing the transaction utilizing 

3 data included in the instruction file, generating response data, and providing a 

4 client response document comprising the response data in a specified 

5 document format corresponding to the client. 

6 10. The specified document format may be defined by a style sheet which includes 

7 a plurality of document fields and the step of providing the client response 

8 document may comprise populating each document field by matching data from 

9 the response data to a document field. More specifically, the response data 

10 may comprise a plurality of data fields and a plurality of predetermined tags, 

1 1 each tag identifying one of the plurality of data fields and the step of populating 

12 each document field comprises matching the field to a tag identify data for 

13 inclusion within the document field. 

14 11. Further, one of the predetermined tags may identify a data field which identifies 

15 the billing client associated with the transaction and the step of providing a 

16 client response document may comprise identifying the billing client and 

17 selecting a document format associated with the billing client for providing the 

18 client response. 

19 12. The response data may be formatted an XML message and the client response 

20 document is an HTML document. 

21 

22 BRIEF DESCRIPTION OF THE DRAWINGS 

23 13. Figure 1 is a block diagram of an electronic bill presentment and payment 

24 system consistent with the present invention; 

25 14. Figure 2 is a flowchart illustrating exemplary operation of a web server in 

26 accordance with one embodiment of the invention; 

27 15. Figure 3 is a flowchart illustrating exemplary operation of an application server 

28 in accordance with one embodiment of the invention; 
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1 16. Figure 4 is a flowchart illustrating exemplary invoice loading in accordance with 

2 one embodiment of the invention; 

3 17. Figures 5a, 5b, and 5c are workflow diagrams illustrating exemplary host user 

4 operations in one embodiment of the invention; 

5 18. Figures 6a, 6b, and 6c are workflow diagrams illustrating exemplary biller 

6 system operations in one embodiment of the invention; 

7 19. Figures 7a, 7b, and 7c are workflow diagrams illustrating exemplary biller 

8 system administration operations in one embodiment of the invention; 

9 20. Figures 8a, 8b, and 8c are workflow diagrams illustrating exemplary payer 

10 system operations in one embodiment of the invention; 

11 21 . Figures 9a and 9b are workflow diagrams illustrating exemplary payer system 

12 invoice/payment operations in one embodiment of the invention; 

13 22. Figure 1 0 is a workflow diagram illustrating exemplary payer system reporting 

14 operations in one embodiment of the invention; and 

15 23. Figure 1 1 is a workflow diagram illustrating exemplary payer system 

16 administration operations in one embodiment of the invention. 

17 

18 DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 

19 Exemplary Bill Presentment and Payment System 

20 24. Figure 1 illustrates an electronic bill presentment and payment system 10 

21 consistent with the present invention. System 10 includes at least one biller 

22 system 12, at least one payer system 14, at least one business service provider 

23 system 16, and a payment processing system ("ASP") 18, in communication 

24 with one another via a network 20. The network 20 may be a TCP/IP compliant 

25 network, such as the Internet. It should be appreciated that each of the biller 

26 system 12, payer system 14, business service provider system 16 and ASP 18 

27 (also referred to herein as "workstations") may be remotely located from each 

28 other and may be controlled by separate entities. Alternatively, permutations of 
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1 each of the biller system 12, payer system 14, business service provider system 

2 16 and ASP 18 may be commonly controlled and/or located at a single entity. 

3 25. The biller system 12 and payer system 14 may interface with the ASP 18 in real 

4 time via a web browser or other TCP/IP compliant software. The biller system 

5 12 and payer system 14 may comprise computing devices with appropriate 

6 network interface hardware and software for establishing a TCP/IP session with 

7 a web server 30 at the ASP 18 and for executing an application for interfacing 

8 with the web server 30. The application may be typical HTML Internet web 

9 browser software, such as Netscape Navigator™ or Microsoft Internet 

10 Explorer™, which is capable of receiving HTML documents from the web server 

1 1 30 and returning HTTP posts to the web server 30. It should be appreciated 

12 that such HTML interface enables an operator of a biller system 12 or payor 

13 system 14 to read, write, manipulate data, and otherwise interact with the ASP 

14 in real time. 

15 26. The biller system 12 and payor system 14 may also interface with the ASP 18 

16 utilizing a batch interface for exchanging large quantities of data in data files of 

17 a predetermined format. The batch interface may use TCP/IP or other network 

18 type sockets or may utilize a dedicated network circuit such as a value added 

19 network (VAN). 

20 27. The business service provider system 16 may be an exchange or other service 

21 bureau application providing a plurality of business processing services to its 

22 clients (which may include the biller system 12 and/or payer system 14). One 

23 such business processing service may be electronic bill presentment and 

24 payment, as may be provided using a system and/or method consistent with the 

25 invention. In such a configuration, from the point of view of the service provider 

26 system 16, the ASP 18 may be a back end system for performing such bill 

27 presentment and payment portions of the overall services. The service provider 

28 system 16 may communicate with the ASP 18 utilizing data files with a 

29 predefined format to assure that the content of such data files may be 

30 recognized by the intended hardware and/or software. The predetermined data 
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1 file may be a data file with each data element including a label or tag to identify 

2 the data. 

3 28. A typical language for structuring such tagged field data files is known as the 

4 extensible markup language (XML) and the predetermined data structure is 

5 known as a schema. The data is referred to as an XML message. Utilizing the 

6 Internet 20, the service provider system 16 and the ASP 18 may establish a 

7 TCP/IP session and exchange XML messages. 

8 29. It should be appreciated that, in an alternative embodiment, a biller system 12 

9 or a payer system 14 may operate an accounting system interface application 

10 rather than a web browser. In this case, the biller system 12 or payer system 

11 14 will communicate with the ASP 1 8 utilizing XML messages, and the XML 

12 communication may be similar to that which may occur between the ASP 18 

13 and the service provider system 16. Such an accounting system interface 

14 application may enable the biller system 12 or payer system 14 to avoid 

15 manually reading data from an HTML document and manually re-entering into 

16 an accounting system. More specifically, the XML messages may be used to 

17 directly input content into the accounting system or, at a minimum, 

18 automatically populate content onto an accounting system data entry screen. 

19 30. The ASP 1 8 may comprise one or more web servers 30 coupled to a secured 

20 zone network 22 between two routers 24, 26 serving as firewalls, one for 

21 protecting the internal private network 28 of the ASP 18 and one for blocking 

22 unauthorized Internet access. This zone 22 is often referred to idiomatically as 

23 a DMZ (i.e. "de-militarized zone"). It is noted that one or more firewalls may be 

24 placed between any one of a number of components of the present invention 

25 for security purposes. In this standard firewall configuration of a DMZ 22, the 

26 web servers 30 may be coupled to the Internet 20 by a first router 24 and 

27 coupled to a private network 28 by a second router 26. On the "front end", the 

28 web servers 30 may establish the TCP/IP sessions and communicate with the 

29 biller systems 12, payer systems 14, and business service provider systems 16, 

30 as described above. On the back end, the web servers 30 may use XML 
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1 messages to make remote processing calls (RPCs) to an application server 32 

2 (described hereinbelow in further detail) and may receive XML response 

3 messages to such calls. An invoice loader 34 (described hereinbelow in further 

4 detail) may be provided for transmitting batch input to a database server 36, 

5 which may store invoice and other financial, transactional, or non-financial data. 

6 Those skilled in the art will recognize that such data may be generated by one 

7 of any number of billing systems, e.g., SAP, Oracle Financials, JD Edwards, 

8 People Soft, Great Plains, etc. The data outputted by these billing systems and 

9 input into the system may come in a variety of formats including raw data, print 

10 file format, and X-12 ANSI 810 (EDI). The database server 36 may include a 

11 database application 35 (described hereinbelow in further detail) for reading 

12 and writing to the raw data stored on the magnetic media of the database. 

13 Web Server 

14 31 . With reference to the flowchart of Figure 2 in conjunction with Figure 1 , an 

15 exemplary fundamental operation of a web server 30 in accordance with one 

16 embodiment of this invention is shown. A TCP/IP session may be established 

17 at step 40 with a remote client, which includes appropriate exchanges of 

18 passwords and/or other authentication messages to verify that the remote client 

19 has authorized access. Clients may be either workstations which interface with 

20 the server 30 using a browser interface, or, alternatively, software clients which 

21 interface with the server 30 using XML messages. Step 42 represents a 

22 determination as to whether the remote client is operating a web browser or 

23 whether the client is operating an XML enabled application. If the remote client 

24 is operating a web browser, the server 30 may send out an initial HTML 

25 document to the client at step 48. This initial document may be the main menu 

26 page that the operator at the remote client might expect to see immediately 

27 after logging onto the system utilizing the browser. The server may then 

28 receive an HTTP post from the remote client at step 50 and, in response to 

29 such HTTP post, build an XML message for making a remote processing call to 

30 the application server 32 at step 52. More specifically, the XML message is 

31 based on the content of the post and a predetermined schema for the function 
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1 that the operator of the remote client has requested via the HTTP post. For 

2 example, if the operator had selected to view a list of open invoices from the 

3 HTML menu document, the server might build an XML message for requesting 

4 open invoices from the application server 32 based on the schema for viewing a 

5 list of open invoices in response to the HTTP post. 

6 32. Step 54 represents the server making an XML remote processing call to the 

7 application server 32 utilizing the XML message. An XML response message 

8 may be received back from the application server 32 at step 56. The web 

9 server may then utilize the content of the XML response message to build an 

10 HTML document to send to the remote client in response to the remote client's 

1 1 HTTP post at step 58. More specifically, each web server 30 may include a 

12 style sheet database 52 that stores style sheets for various documents that may 

13 be sent to remote clients and may provide different style sheets for the same 

14 document based on different clients. As such, the branding, look and feel, and 

15 layout of documents may be varied on a client-by-client basis. The step of 

16 building an HTML document may therefore also include selecting a style sheet 

17 corresponding to the remote client and combining the style sheet with the 

18 content of the XML response message to build the HTML document. The style 

19 sheet may include data fields and building the HTML document may include 

20 populating the style sheet by matching data elements from the response 

21 message with fields on the style sheet. The HTML document may then be sent 

22 to the remote client at step 59, and, returning to step 50, another HTTP post 

23 may be received and the foregoing steps repeated for that HTTP post. 

24 33. Because it is envisioned that the operator of the biller system 1 2 (Figure 1 ) may 

25 provide electronic bill presentment and payment services to several of it 

26 suppliers, each operating a payor system 14, it is envisioned that style sheets 

27 will be common to all biller systems 12 and payor systems 16 when interfacing 

28 with the ASP 18 with respect to reading, writing, and manipulating data at the 

29 ASP 18 related to amounts due to the biller operating the biller system 12. In 

30 which case, a style sheet is selected by identifying the biller system 12 utilizing 
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1 an element of the response message and selecting a style sheet corresponding 

2 to such biller system 12. 

3 34. Similarly, It is envisioned that he operator of a payor system 1 3 may provide 

4 electronic bill and payment services to several of its customers, each operating 

5 a biller system 12. It is envisioned that style sheets will be common to all biller 

6 systems 12 and payor systems 16 when interfacing with the ASP 18 with 

7 respect to reading, writing, and manipulating data at the ASP 18 related to 

8 amounts due to the biller operating the biller system 12 from such operator of 

9 the payor system 13 providign the services to its customers. In which case, a 

10 style sheet is selected by identifying the payor system 14 utilizing an element of 

11 the response message and selecting a style sheet corresponding to such payor 

12 system 14. 

13 35. Alternatively, if at step 42 the remote client is determined to be a client utilizing 

14 an XML enabled application instead of a web browser, the web server may 

15 send an initial XML message to the remote client at step 60. The web server 

16 may then receive an XML message from the remote client at step 62 and 

17 validate the XML message at step 64. If necessary, the content may be 

18 transformed into an XML message compliant with the schema needed for 

19 making a remote processing call to the application server at step 67 if it did not 

20 validate at step 64. 

21 36. The schema-compliant XML message may then be used to make the remote 

22 processing call to the application server at step 66. At step 68, a response XML 

23 message may be received from the application server, and, at step 70, the 

24 response XML message may be returned to the remote client. Thereafter, 

25 returning to step 62, another XML message may be received and the foregoing 

26 steps may be repeated. 

27 37. It should be appreciated that the above description represents an exemplary 

28 process utilized for interacting with each remote client. In operation, the server 

29 may be operating with a plurality of remote clients simultaneously and/or 

30 utilizing a multi-tasking based operating environment. Furthermore, a plurality 
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1 of web servers 30, each communicating with a plurality of different clients, may 

2 each be capable of making XML calls to the application server 32 to perform the 

3 above described functions. 

4 Application Server 

5 38. The application server 32 may perform the main processing of the business 

6 functions carried out by the ASP 18. The application server 32 may operate 

7 within a hardware and software environment. The software environment may 

8 comprise a plurality of applications that may be object-oriented and/or table- 

9 driven, whereby new products, applications, modules and/or transaction types 

10 may easily be integrated. Such software components may include, e.g., an 

1 1 operating environment 41 (e.g. Microsoft Windows NT™, Windows 2000™, or 

12 Sun Solaris™), transaction processing software (e.g. Microsoft Transaction 

13 Server™), communications software, database tools (e.g. RogueWave™), 

14 query and/or reporting software (e.g. Seagate's Crystal Reports™), a database 

15 interface 33, a message parser/builder 51 , a business function selection object 

16 38, one or more business objects 37, and/or one or more other applications, 

17 which may be table-driven. As described hereinbelow with respect to Figure 3, 

18 the message parser/builder 51 may verify access levels of clients accessing the 

19 web servers 30, as well as verify the format of XML messages and build 

20 appropriate messages to pass to the appropriate selection objects 37 for 

21 execution. 

22 39. The transaction processing software may be a component-based transaction 

23 processing application for developing, deploying, and managing high 

24 performance, scalable, and robust enterprise, Internet, and intranet server 

25 applications, which defines an application programming model for developing 

26 distributed, component-based applications and provides a run-time 

27 infrastructure for deploying and managing these applications. A clustering 

28 application may optionally be provided for load balancing and fail-over services 

29 to cluster distributed application servers into a single, high-performance, highly 

30 available environment of application server resources, thereby avoiding 
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1 bandwidth, latency, and congestion problems and providing multi-server 

2 scalability for unlimited concurrent user access. The query and/or reporting 

3 software may be an application or object providing for an environment in which 

4 client reports and file download formats are easily customizable. One or more 

5 business objects 37 or applications may reside on the application server 32, 

6 such business objects 37 or applications being the components that perform the 

7 central transactional functions of the server 32. The business objects may 

8 receive XML messages in a predefined format and return XML response 

9 messages in a predefined format. Menus of options (as shown in Figures 5- 

10 1 land described hereinbelow) may be made available to the client by the 

1 1 message parser/builder 51 (or, as those skilled in the art will recognize, by one 

12 of any number of components of the invention, e.g., selector or another 

13 business object). 

14 40. As discussed hereinbelow, exemplary business objects may include an object 

15 for reviewing invoices, an object for making adjustments to invoices, and an 

16 object for initiating invoice payment. One or more of any of the foregoing 

17 described applications may access the database server 36 via the database 

18 interface 33 and/or database application 35 for purposes of retrieving and 

19 modifying its data. Other applications may be provided, consistent with the 

20 provision of billing, payment, or other financial or non-financial services. For 

21 example, an e-mail notice application may be provided for sending e-mail 

22 notices of the invoices to one or more payer systems 14 which are set up to 

23 receive e-mail notices. While the foregoing components of the application 

24 server 32 may be referred to herein as "applications", "modules", "components", 

25 "interfaces", and/or "objects", it should be understood by those skilled in the art 

26 that such labels should not be construed in any way to be limitations. Any of 

27 the components of the application server 32 may comprise machine-readable 

28 programming code embodied in a tangible medium, e.g., Java beans. 

29 Depending on whether the embodiment of the invention is object-oriented, such 

30 components may or may not be formal objects. A table at the end of this 

31 Detailed Description lists exemplary objects and corresponding XML messages 
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1 in one embodiment of the invention. It is noted that the business objects of the 

2 present invention should be modular, i.e., functionality may be added to, 

3 deleted from, or modified in the system by adding or removing business objects. 

4 Thus, each business object should be constructed with expected input and 

5 output data only, as though it were a "black box". The internal processes of 

6 each business object "black box" are not relevant to the overall operation or 

7 maintenance of the system, to the extent that any business object with a given 

8 set of expected input and output data may be substituted for an existing 

9 business object for performing a similar or identical function having the same 

10 set of expected input and output data, wherein the system need not ever 

1 1 require knowledge of the internal operation of the business object for proper 

12 functioning or maintenance. 

13 41 . With reference to the flowchart of Figure 3, which illustrates an exemplary 

14 operation of the application server 32 in one embodiment of the invention, in 

15 conjunction with Figure 1 , the general operation of the application server 32 will 

16 now be described. First, an XML remote processing call may be received at 

17 step 72 from one of the web servers 30. The message parser/builder 51 may 

18 receive from the web servers 30 either an XML message from the software 

19 client or an HTTP post from the workstation client. If an XML message is 

20 received from a software client, the message parser/builder 51 may verify that 

21 the particular client has appropriate access levels for sending such XML 

22 message, thereby preventing a person from manually writing an XML message 

23 for an option that is outside of the permitted workflow for the client. After 

24 verifying access levels, the message parser/builder 51 may verify that the XML 

25 message is the exact format needed for passing to the selection object 37. If 

26 not, data may be extracted and the appropriate message is built. The message 

27 may then be passed to the selection object 37, which may pass the message to 

28 the appropriate business object 37 for execution. In the case of an HTTP post 

29 from a workstation, the message parser/builder 51 may build an XML message 

30 for performing the transaction based on the post and the access levels. The 



13 



1 message may then be passed to the selection object 37, which may pass the 

2 message to the appropriate business object 37 for execution. 

3 42. A business function selection object 38 may then make a call at step 74 to the 

4 appropriate business object 37 associated with the XML call. The selected 

5 business function object may execute and generate at step 76 XML calls to the 

6 database interface 33. The database interface 33, in turn, may utilize 

7 predefined instructions at step 78 for directing the database server 36 to access 

8 and/or write data into the database tables. In one embodiment, the predefined 

9 instructions may be a group of instructions, e.g., SQL calls. It is noted, 

10 however, that the business function objects 37 may not directly perform the 

1 1 SQL calls at step 78. The database interface 33 object may exist so that the 

12 relational structure of the database 36 may be modified without modifying each 

13 of the business function objects 37. Each database relational structure may 

14 merely need to be defined in a database structure file (not shown) that may be 

15 used by the database interface 33 object to structure the appropriate SQL calls 

16 for execution at step 78. A response to the SQL call may then be received at 

17 step 80 from the database 36. A single XML call at step 76 from a business 

18 function object 37 may cause the database interface 33 object to initiate several 

19 SQL calls at step 78. Therefore, if more than one SQL call is necessary (as 

20 determined at step 90), a plurality of such calls may be initiated at step 78, as 

21 necessary, and the corresponding responses may be received at step 80. 

22 Once the database interface 33 object has completed the SQL calls at step 78, 

23 it may build (at step 82) and return (at step 83) a response XML message to the 

24 business function object 37. The response XML message may then be received 

25 at step 84 by the business function object 37. A business function object 37 

26 may need to initiate several XML calls to the database interface 33 object 

27 during performance of the selected business function, at step 76. Therefore, if 

28 more than one XML call is necessary (as determined at step 85), a plurality of 

29 such calls may be initiated at step 76, as necessary, and the corresponding 

30 database calls may be generated (at step 78) and may be received (at step 80), 

31 and appropriate XML responses may be built (at step 82), returned (at step 83), 
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1 and received (at step 84). Once the XML calls to the database interface have 

2 been completed at step 76, (i.e. the business function has been completed), the 

3 business function object 37 may build a response XML message at step 86 and 

4 may return the XML response message to the web server 30 at step 88, and 

5 the foregoing steps repeated for a subsequent XML remote processing call 

6 which may be received at step 72. 

7 Invoice Loader 

8 43. With reference to the flowchart of Figure 4, which illustrates an exemplary 

9 invoice loading operation in one embodiment of the invention, in conjunction 

10 with Figure 1 , the general invoice loader 34 operation will now be described. 

11 The invoice loader 34 module may provide batch input to the database 36. This 

12 may be useful because many enterprise accounting systems may export an 

13 invoice file on a periodic basis. The batch invoice file may then be sent at step 

14 100 to the invoice loader module 34 via one of any number of means 53, e.g., 

15 as an e-mail attachment, FTP load, an EDI VAN (value added network), or 

16 another private network link. Therefore, the invoice loader module 34 may 

17 include a network interface (not shown) for coupling to the Internet and may 

18 include one or more private network interfaces (not shown) for coupling to EDI 

19 VAN's or other private network interfaces. Each of these network interfaces 

20 may be a network card, or may comprise such other hardware and software as 

21 may be appropriate to effect the network interconnection. Alternatively, the 

22 invoice loader module 34 may couple only to a local area network 28 at the 

23 processing facility (i.e. at the geographic location of the ASP 18), and one or 

24 more routers 24, 26 in the DMZ 22 may serve to couple the invoice loader 34 to 

25 the Internet 20 and to each private network, as may be appropriate. 

26 44. Once the invoice loader module 34 receives the invoice file at step 102, it may 

27 verify that the file is in the appropriate invoice loader format at step 104. 

28 Typically, the biller may be responsible for running the necessary translation 

29 program to convert the invoice file from the biller's accounting system to the 

30 invoice loader format. However, it may be possible for the file to arrive at the 
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1 invoice loader module in the accounting system format, in which case the 

2 invoice loader module may then identify the accounting system format and run 

3 an appropriate translation program at step 106 to convert to invoice loader 

4 format. Exemplary formats from which invoices may be loaded include ANSI 

5 X12 810, flat ASCII files, or well formed XML schemas. 

6 45. Once the invoice file is in the invoice loader format, the invoice loader module 

7 34 may enter the invoices into the database 36 at step 108 and may, if 

8 appropriate, send out e-mail notices at step 1 14 to one or more payer system 

9 14 users indicating that an invoice is available. To this end, the invoice loader 

10 module 34 may therefore include an invoice loader application 39. The invoice 

11 loader application 39 may make appropriate calls to a database application 35 

12 for loading the invoices. More specifically, the database application 35, which 

13 may run on the database server 36 (or, alternatively, on the application server 

14 32), may provide for the raw data stored on the magnetic media to be logically 

15 accessible in a relational database table format. Predefined instructions for 

16 accessing and writing data into the tables may be sent to the database 

17 application 35. In one embodiment, the predefined instructions may be a group 

18 of instructions, e.g., SQL calls. The invoice loader application 39 may therefore 

19 execute appropriate SQL calls for writing the invoice data to the database 36. 

20 46. Once the invoice data is in the database 36, e-mail notices of the invoices may 

21 be sent out to one or more payer system 14 users who are set up to receive e- 

22 mail notices at step 114. An e-mail notice application 31 may be provided on 

23 the application server 32 for making appropriate SQL calls to the database 36. 

24 Such calls may be made for purposes of detecting new invoices at step 1 10, as 

25 well as determining, based on the identity of the payer, if an e-mail notice is 

26 required, at step 112. More specifically, the e-mail notice application 31 may 

27 search the database 36 for a flag or other identifier of a new invoice, and then, 

28 for each new invoice, may obtain data from a payer's profile indicating whether 

29 an e-mail notice is appropriate, and if appropriate, the address to which the e- 

30 mail notice should be sent. The e-mail notice application 31 may then send the 
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1 e-mail. Alternatively, the e-mail notice application 31 may run on the invoice 

2 loader module 39 instead of running on the application server 32. 

3 Database Server 

4 47. The database server 36 may be an OLTP (on-line transaction processing) 

5 system, embodied in a server, such as Microsoft SQL Server 7™, Oracle 8™, 

6 Sybase Adaptive Server R12™, DB2™, Informix™, or another ODBC-compliant 

7 database. The database server 36 may be configurable for sharing with other 

8 applications, including access by a report writer application, and may comprise 

9 a distribution and replication protocol (DRP) device. A backup database server 

10 (not shown) may also be provided, wherein some or all of the data on the 

1 1 database server may be mirrored to the backup database server. In this 

12 configuration, in the event an application performing a transaction on the 

13 database server experiences failure, the application may start at the backup 

14 server location and proceed from the point of failure, thereby preserving 

15 transaction integrity. 

16 48. The database 36 may be a relational database, i.e., data management 

17 technology modeled such that all data is organized as though it is formatted into 

18 tables, with the table columns representing the table's fields or domains and the 

19 table rows representing the values of the table's fields or domains. Data 

20 between tables may be related to one another, using, for example, pointer data. 

21 Data may be logically organized as tables but not necessarily physically stored 

22 as such. The database interface 33 may access and update data via a 

23 language interface or "structured query language" (SQL) calls. The database 

24 36 may comprise a relational database where the payer and biller profiles 

25 (which may include access control data and/or dispute rules) may be related 

26 between payer systems 14 and biller systems 12. The message parser/builder 

27 51 may retrieve access control data from the database 36 when a workstation 

28 client logs on. Similarly, business service provider profiles may be stored in the 

29 database 36 and may include access control data for one or more business 

30 service providers 16. 
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1 49. Invoice data stored on the database 36 may include invoice-specific data 

2 received from the biller 12 each time the biller 12 sends an invoice to the ASP 

3 18. Such data may include, e.g., the identity of the biller and payer, invoice line 

4 items, and settlement and payment options. Biller profile data may be stored on 

5 the database 36 and may include items that a biller 12 need only enter once, 

6 and may change only periodically thereafter. Such items may include dispute 

7 rules and access levels for each biller workstation with system access. The 

8 dispute rules may be payer-specific or may be may applied globally to all 

9 payers. 

10 50. Payer profile data may be stored on the database 36 and may include items 

11 that a payer 14 need only enter once, and may change only periodically 

12 thereafter. Such items may include access levels for each payer logon ID 

13 (referred to as a payer workstation) with system access. 

14 Client Types 

15 51 . In one embodiment, two client types may access the ASP 18, a workstation 

16 client (e.g. a browser) interfacing with the system 18 utilizing HTML documents 

17 and HTTP posts, and a software client interfacing with the system 18 utilizing 

18 XML messages. Both billers and payers may comprise workstation clients, and 

19 the message parser/builder 51 may present different work flow options to each 

20 via menus. Host (or "administrator") users and help desk users may be biller or 

21 payer workstations having access levels which are a subset of all access 

22 options available to the biller or payer. Host users (who may be affiliated with a 

23 business service provider system) may control most non-invoice related data 

24 and functionality. A biller system user may control invoice related data and 

25 functionality associated with a specific billing company. A payer system user 

26 may have specific functionality associated with all related invoice transactions 

27 to the paying company. Help desk users may be provided access to the system 

28 in order to troubleshoot users' questions. 

29 52. Host users (also referred to herein as "administrators") may configure and 

30 maintain the system. A single SuperUser account may be established for each 
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1 installation of the system. The SuperUser may be pre-configured with the 

2 system and have all permissions allowed. The SuperUser may create additional 

3 host users with a subset of their permissions. Host users may act as system 

4 administrator, whose role is to manage users in the system, handle database 

5 administration, monitor system activity, manage enrollment and handle system 

6 error conditions. 

7 53. A host user may create a biller system and one or more biller administrator 

8 users associated with such biller system. This action may bind the specific 

9 biller system user to the invoices associated with the biller. Additional biller 

10 system users may be created by the biller administrator. 

1 1 54. Similarly, A host user may create a payer system and one or more payer 

12 administrator users associated with such payer system. 

13 55. A help desk user may be a hybrid type of user. The help desk user may 

14 manage technical support issues. This user may log in as any biller or payer 

15 system user and use the system as if they were actually that user. The 

16 application may disallow any changes made by this user from being committed 

17 to the database. The help desk user may be created by a host administrator or 

18 SuperUser. A user created as a help desk user may only perform the help desk 

19 functionality, with all other system functionality being disabled. 

20 56. A help desk user may log on to the system through the standard logon page 

21 with their own user ID and password. The help desk user may then be 

22 immediately presented with the standard logon page, where he or she will then 

23 log on with the user ID of the person he or she is helping and the help desk 

24 user's password. Upon a successful log on, the help desk user may be 

25 connected as if he or she were the actual user, without the ability to modify any 

26 data. 

27 Login and Access 

28 57. The application server 32 may authenticate each client via a logon process, and 

29 each : client may have a specific set of access levels for performing certain 
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1 functions, which may be a subset of all of the functions available to the 

2 particular biller, payer or business provider. The message parser/builder 51 

3 may maintain a table of access levels for each client which is currently logged 

4 into the system. With respect to transaction requests, when an HTTP post is 

5 received from a workstation or an XML message is received from an application 

6 client, the message parser/builder 51 may only build the XML message from the 

7 HTTP (or pass the XML message received) if the client has appropriate access 

8 levels. With respect to responding to a transaction request, the message 

9 parser/builder 51 may control the clients' work flow and limit the menu choices 

10 which appear in the outbound XML message to those that would be available 

1 1 as next steps in the work flow for the particular client. 

12 58. The system may permit a user (i.e. the operator of a biller, payer or business 

13 service provider workstation) to gain access by clicking on a "login" button on 

14 the initial screen, or by going directly to the logon URL without having to 

15 navigate through the initial pages by simply entering the full URL in the browser, 

16 "bookmarking" the page, or using a "favorites"-type feature of the browser. The 

17 system may present the user with a logon page, wherein he or she must specify 

18 a valid user ID and password to gain access. If an invalid ID or password is 

19 entered, the user may be told that an invalid ID/password was entered. In one 

20 embodiment, if a user enters a valid user ID and an invalid password five times 

21 in a row, the system may "disable" the user ID (i.e. the system 18 will not 

22 present the workstation defined by the ID with other system options until 

23 another workstation, with appropriate access levels, performs a function to reset 

24 the "disabled" account). If, after this period, the user enters a valid ID and 

25 password, the system may display a message indicating that their account has 

26 been disabled. 

27 59. Alternative authentication methods may include any method of verifying the 

28 identity of a user or a component of the invention and may include a security 

29 mechanism such as one or more of a digital signature, a PIN number, a 

30 password, a smart card, or a "master" or "challenge" key. In one embodiment 

31 of the invention, an XML script may create a Java applet that monitors the 
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1 active application and interacts with a separate security server residing within 

2 the application server. The Java applet may be configurable to interrupt the 

3 current application to prompt for authentication, such as by a digital signature, a 

4 PIN number, a password, or a master key, and to communicate with the 

5 security server to effect the authentication. If the security operation is 

6 successful, the application may continue without interruption; otherwise, the 

7 application may be terminated according to the XML script. Alternatively, the 

8 foregoing process or a part thereof may be used for transferring data between 

9 any two components in an embodiment of the present invention, including those 

10 external to the invention, such as an end user, a client, a financial institution, a 

1 1 back office, an administrator, an e-mail or fax recipient, or a server. One or 

12 more of the foregoing security operations may be implemented using 

13 application security middleware, such as Ubizen's MultiSecure™ ETS, 

14 MultiSecure™ ASE, or MultiSecure™ WAC. Further security means may 

15 comprise one or more of the following: password or PIN number protection, use 

16 of a semiconductor, magnetic or other physical key device, biometric methods 

17 (including fingerprint, nailbed, palm, iris, or retina scanning, handwriting 

18 analysis, handprint recognition, voice recognition, or facial imaging), or other 

19 log-on security measures known in the art. Password protection may include 

20 certain validity requirements upon establishing a password, e.g., disallowing 

21 more than two consecutive characters in a password, disallowing the same 

22 password for a minimum of six consecutive password changes, and/or 

23 disallowing more than one user-initiated password change per day. Passwords 

24 may be set to expire after a certain number of days, and an inactive user 

25 account may be set to expire or become disabled after a certain number of days 

26 of nonuse. 

27 60. Following logon, as described above, a user may be presented with 

28 predetermined work flow options based on the access levels available for his or 

29 her particular workstation. 
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1 Security 

2 61 Point-to-point data communications over the Internet may be handled by secure 

3 sockets between the web server 30 and client 12, 14, 16. Exemplary protocols 

4 used may include Netscape's Secure Socket Layer (SSL) or secure HTTP. As 

5 those skilled in the art will recognize, other embodiments of the invention may 

6 include one of any number of methods for two-way data encryption and/or 

7 digital certification for data being input to and output from the web server 30, to 

8 provide security to data during transfer. In particular, an algorithm such as 

9 Triple DES may be used to encrypt such data as account numbers, credit card 

10 numbers, tax ID numbers and/or passwords. 

11 Host User Workflow 

12 62. Figures 5a, 5b, and 5c illustrate an exemplary host user workflow in one 

13 embodiment of the system. When a user logs in 501 to the system using the 

14 user ID of a host user, the system may display a host administration or 

15 "welcome" page 502. The system may display the user's name at the top in the 

16 form of a "Welcome , Username ,,, message, for personalization. The system 

17 may display a host administration page containing host statistics and a list of 

18 "action items" with current counts and links to the corresponding pages. Such 

19 counts may include biller count, payer count, enrollment request count, 

20 connected user count, invoice load error count, total invoice count, and paid 

21 invoice count. The system may calculate these reported statistics at the time 

22 the active user logs on to the system and/or may update these statistics in real 

23 time. As part of reporting these statistics, a query tool may be integrated into 

24 the system to generate pre-formatted reports. The system may permit the host 

25 user to return to this page by clicking on a link that may be present on every 

26 page during system access. One area of the screen may contain navigation 

27 buttons grouped into categories, e.g., administration 503 and reports 504. The 

28 system may permit these categories to be expanded into subcategories that 

29 modify another portion of the screen. One area of the navigation frame may 

30 contain the user name (not the user ID) who is logged on. The system may 
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1 permit clicking on this link to modify the user's basic profile information, which 

2 the system may store as global information on the database. 

3 63. The system may permit a host user to select an option to edit payers 507, 

4 wherein the system may permit the administrator to add, modify, or delete 

5 payers from an edit payer page 508. A payer may be a company that does 

6 business with one or more billers in the system. Each payer system may have 

7 one or more users that will have certain permissions. The edit payer page 508 

8 may contain a list of current payers in the payers list box. When an 

9 administrator selects a payer, the system may display information for that payer 

10 in the company information section. The system may permit an administrator to 

11 add information for a new payer in the company information section and select 

12 "add" to add the new payer. The system may permit company data to be 

13 entered for the following exemplary fields, which the system may store as global 

14 information on the database: name, "division", address, city, state, zip, country, 

15 SIC code, TIN, and organization type. The system may require the company 

16 name plus "division" to be unique. The system may permit modify and delete 

17 operations to be performed on the currently selected payer. The system may 

18 require fields for company information, such as name and phone. The system 

19 may display the list of payers and permit search and find operations, next and 

20 previous page navigation, first letter selector navigation, and scrolling 

21 navigation, in order to effectively display large numbers of payers. 

22 64. The system may provide a user list box, which may be populated with the 

23 selected payer system's user names. As the administrator clicks on each user 

24 in the list, the system may display the user's information in the user information 

25 section. The system may provide an "edit users" option for directing the 

26 administrator to an "edit users" page, if the payer has been saved to the 

27 database. The system may provide an "edit users" page to allow the 

28 administrator to add, modify, or delete users associated with the current payer. 

29 This page may display the name of the payer at the top. The system may 

30 permit the host user to select an option to edit the active user profile 505, 

31 wherein the system may direct the host user to a page 506 displaying the 
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1 organization name of the host, biller or payer at the top, to establish the context 

2 of the current edit. The system may permit information to be maintained and 

3 edited at this page, which the system may store as global information on the 

4 database, including, e.g., last name, first, middle, phone, fax, e-mail, e-mail2, 

5 user id, password, confirmation, language, currency and privilege group. The 

6 system may require certain fields for user information, such as last name, first 

7 name, e-mail and phone. The system may provide a reset password button to 

8 reset the selected user's password to the default setting (e.g. user's last name). 

9 The system may also permit the administrator to add a new user to the current 

10 payer by entering information into the user information section and selecting 

11 "add". The system may require the combination of last name, middle initial and 

12 first name to be unique. The system may permit modify and delete operations to 

13 be performed on the currently selected user. The system may provide a 

14 checkbox for temporarily deactivating a user. The system may automatically 

15 send an e-mail to a new user after they have been added, informing them of 

16 how to connect and logon to the system. The system may not permit a host 

17 user to set permissions. The system may permit a host user to create biller or 

18 payer system administrator users, both of whom may be afforded all 

19 permissions. 

20 65. The system may permit the host user to select an option to edit billers 509, 

21 wherein the system may permit the administrator to add, modify, or delete 

22 billers from an edit biller page 510. A biller may be a company that does 

23 business with one or more payers in the system. Each biller system may have 

24 one or more users that will have certain permissions. The edit biller page 510 

25 may contain a list of current billers in the biller list box. When an administrator 

26 selects a biller, the system may display the information for that biller in the 

27 company information section. The system may permit the administrator to add 

28 information for a new biller in the company information section and select "add" 

29 to add the new biller. The system may permit company data to be entered for 

30 the following exemplary fields, which the system may store as global 

31 information on the database: name, address, city, state, zip, country, SIC code, 
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1 TIN, and default template type. The system may require that the company 

2 name be unique. The system may permit modify and delete operations to be 

3 performed on the currently selected biller. The system may require certain 

4 fields for company information, such as name and phone. 

5 66. The system may permit a host user to select an option to edit biller websites 

6 and logos, directing the user to a biller website and logo page 51 1 . The system 

7 may display a list of billers, and upon selection of a biller from the list, the 

8 system may populate the company information area with details about the 

9 current biller. For each biller, the system may permit a list of company logos 

10 and websites to be edited. The system may make new logos available to the 

11 system with an "add" button which uploads the logo file, and may likewise 

12 permit logos to be removed from the system with a "remove" button. The 

13 system may display a list of websites via a listbox containing the sites and a site 

14 details edit area. Upon selection of a website in the list, the system may 

15 populate the site details section. The system may permit the URL, description, 

16 and type of website to be edited. The system may provide a delete button for 

17 removing a site from the list. The system may provide a save button to save 

18 the current website. The system may provide a new site button for emptying 

19 the edit area to allow a new site to be entered and saved. The system may 

20 provide selectable links for accessing the biller's enrollment page and biller 

21 profile page. The system may be adapted to store logo and website data as 

22 global information on the database. 

23 67. As described above with respect to users associated with payers, the system 

24 may provide a user list box, which the system may populate with the selected 

25 biller system's user names, and the system may provide an "edit users" option 

26 for directing the user to an "edit users" page, where the system may allow the 

27 administrator to add, modify, or delete users associated with the current biller. 

28 68. The system may permit the administrator to add a new user to the current biller 

29 by entering information into the user information section. The system may 

30 require that the combination of last name, middle initial and first name be 
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1 unique. The system may permit modify and delete operations to be performed 

2 on the currently selected user. The system may provide a checkbox for 

3 temporarily deactivating a user. The system may be adapted to store contact 

4 information as global information on the database, including, e.g., last name, 

5 first, middle, phone, fax, e-mail, e-mail2, user ID, password, confirmation, 

6 language, currency and privilege group. The system may require certain fields 

7 for user information, including last name, first name, e-mail and phone. The 

8 system may provide a reset password button for resetting the selected user's 

9 password to the default setting. The system may be adapted to automatically 

10 send an e-mail to a new user after they have been added, telling the user that 

1 1 they have 24 hours to log in and change their password or the account will be 

12 disabled (e.g. where the password is set to the default of user's last name; 

13 accounts may be re-enabled by a host user). The e-mail may inform them of 

14 how to connect and logon to the system. 

15 69. The system may permit a host user to select a "relationships" option 512 for 

16 being redirected to a relationships page 513 for viewing, modifying and/or 

17 establishing biller/payer relationships. This page may contain a list of current 

18 billers in the billers list box and two payer list boxes: available payer and related 

19 payer. When a user selects a biller from the list box, the system may update the 

20 two payer list boxes. The available payer list box may contain all payers not 

21 currently related to the selected biller that have been approved by the biller. The 

22 related payer list box may contain all payers currently related to the selected 

23 biller. The system may provide "add" and "remove" buttons to allow payers to 

24 be added or removed from the related payers list. The system may display in a 

25 Payer ID# field the system-wide biller-customer number for the selected payer 

26 from either list. The system may not save this page unless all related payers 

27 have Payer ID#'s and may display a warning message may inform the user of 

28 this condition. The system may be adapted to store payer/biller relationship 

29 data as global information on the database. 

30 70. The system may permit the host user to select an option to add/modify/delete 

31 administrators associated with the host. The system may permit the 
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1 administrator to add a new user to the channel host by entering information into 

2 a user information section and selecting "add". The system may require that the 

3 combination of last name, middle initial and first name be unique. The system 

4 may permit modify and delete operations to be performed on the currently 

5 selected user. The system may provide a checkbox for temporarily deactivating 

6 a user. The system may be adapted to store contact information as global 

7 information on the database, including, e.g., last name, first, middle, phone, fax, 

8 e-mail, e-mail2, user ID, password, confirmation, language and privilege group. 

9 The system may require certain fields for user information, such as last name, 

10 first name, e-mail and phone. The system may provide a reset password button 

1 1 for resetting the selected user's password to the default setting. The system 

12 may be adapted to automatically send an e-mail to a new user after they have 

13 been added, informing them of how to connect and logon to the system. 

14 71 . The system may permit a host user to select an option 514 to change security 

15 information, in which case the system may permit administrator, biller and payer 

16 security settings to be modified at one or more user security/privilege pages 

17 515. In the various privilege pages, the system may permit the privilege group 

18 to be entered and presented in the local language. The system may present the 

19 list of functional access permissions in the language of the active user. 

20 72. For changing privilege information relating to host administrators, the system 

21 may permit administrator privilege groups to be defined and edited. The system 

22 may display a list of available permissions, the permissions being inherited from 

23 the active user currently logged on. The system may provide a listbox 

24 containing all defined administrator privilege groups, wherein selecting a 

25 previously defined group may cause the system to populate the list with the 

26 corresponding settings. The system may provide an "all" button for setting all 

27 permissions when selected, and a "none" button for clearing all permissions 

28 when selected. The system may permit add, modify and delete operations to 

29 be performed on the current privilege group. The following list may be 

30 representative of exemplary permissions that may be set for host 

31 administrators: create new billing entities; create/maintain new biller system 
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1 administrators; activate new biller system administrators; create new paying 

2 entities; create/maintain new payer system administrators; activate new payer 

3 system administrators; create/maintain new host administrators; maintain biller- 

4 payer relationships; reset biller/payer system administrator user passwords; 

5 maintain adjustment codes; edit mailing lists; and run canned reports. 

6 73. For changing privilege information relating to billers, the system may permit 

7 biller permissions to be defined and edited. The system may display a list of 

8 available permissions, the permissions being inherited from the active user 

9 currently logged on. The system may provide a listbox containing all defined 

10 biller privilege groups, wherein selecting a previously defined group may cause 

1 1 the system to populate the list with the corresponding settings. The system 

12 may provide an "all" button for setting all permissions when selected, and a 

13 "none" button for clearing all permissions when selected. The system may 

14 permit add, modify and delete operations to be performed on the current 

15 privilege group. The following list may be representative of exemplary 

16 permissions that may be set: create/maintain new biller system users; activate 

17 biller system users; create/maintain new biller system administrator users; reset 

18 user passwords; maintain adjustment codes; edit biller bank holidays; edit 

19 biller/payer agreements; edit mailing lists; and run canned reports. 

20 74. For changing privilege information relating to payer system users, the system 

21 may permit payer permissions to be defined and edited. A list of available 

22 permissions may be displayed, the permissions being inherited from the active 

23 user currently logged on. The system may display a listbox containing all 

24 defined payer privilege groups, wherein selecting a previously defined group 

25 may cause the system to populate the list with the corresponding settings. The 

26 system may provide an "all" button for setting all permissions when selected, 

27 and a "none" button for clearing all permissions when selected. The system 

28 may permit add, modify and delete operations to be performed on the current 

29 privilege group. The following list may be representative of exemplary 

30 permissions that may be set: create/maintain new payer system users; activate 

31 new payer system users; create/maintain new payer system administrators; 
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1 reset user passwords; maintain adjustment codes; edit payer bank holidays; 

2 edit biller/payer agreements; edit mailing lists; and run canned reports. The 

3 system may be adapted to store any of the foregoing permission data as global 

4 information on the database. 

5 75. The system may permit a host user to select a "load invoices" option 516 for 

6 being redirected to a page 517 for performing a manual load of selected invoice 

7 files or controlling the automatic loading times of biller uploads. The load 

8 invoice page 517 may contain a list of current billers in a billers list box. When 

9 an administrator selects a biller, the system may use files found in the directory 

10 or subdirectories used for invoice loading associated with the selected biller to 

1 1 populate the invoice files list box. The system may permit the host user to 

12 select one or more files from the invoice files list box and select an option for 

13 loading them at that time, which may force the system to load the selected 

14 invoice files immediately. After the process is complete, the system may display 

15 any error information that occurred during processing may on this page. The 

16 system may handle the automatic loading of invoices through a scheduling 

17 interface. 

18 76. The system may permit a host user to select a "host profile" option 505, which 

19 may direct the user to a host profile page 506 for allowing the host's profile 

20 information and payment method information to be edited. The system may 

21 allow data to be entered for the following exemplary fields, which the system 

22 may be adapted to store as global information on the database: name, address, 

23 city, state, zip, country, phone, number, fax number, and maximum invoice 

24 amount allowed. The system may use the maximum invoice amount allowed 

25 field to establish a threshold for a maximum payment for a single invoice. The 

26 system may permit invoice values that exceed this amount to be loaded into the 

27 system but not to be paid through the system. The system may also permit 

28 payment method information to be modified at this page, i.e. the system may 

29 permit the administrator to define the payment methods that the host has 

30 currently enabled. The system may display a payment methods area consisting 

31 of two listboxes, an available methods box containing all the payment methods 
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1 that are currently unassigned by the host, and an enabled methods box 

2 containing all the methods the host has enabled. The system may provide two 

3 buttons to allow methods to be transferred from box to box. The system may 

4 provide save and cancel buttons at the payment methods area. Exemplary 

5 available payment methods may include ACH debit, credit card/procurement 

6 card, and paper check. 

7 77. The system may permit the host user to select a reports option 504, which may 

8 cause the system to display subcategories that correspond to the available 

9 reports. Exemplary reports the system may generate may include: access 

10 report 521 ; invoice load and error reports 522; invoice payment reports 523; 

11 bottomline payment reports 524; analyze RDBMS (Relational Database 

12 Management System) 525; review performance statistics 526; and activity 

13 report 527. Activity report 527 may cause the system to detail the following 

14 exemplary activities: create new biller/payer; create new contacts; add/remove 

15 biller-payer relationships; edit biller bank holidays; edit biller/payer profiles; 

16 reset biller/payer system administrator passwords; add/edit adjustment codes; 

17 edit mailing lists; edit contact info; create new logins for contacts; edit login info; 

18 disable/enable logins; and help desk login. The system may permit the user to 

19 select from among various reporting options and/or filters 528 (which the 

20 system may be adapted to store as global information on the database), and 

21 the system may then generate a report and permit the user to view and/or print 

22 it at a report page 529. 

23 78. Other functionality which the system may provide for the host user includes a 

24 password change selection 530, which may cause the system to direct the user 

25 to a password change routine 531 ; a help selection 533, which may cause the 

26 system to direct the user to a help routine 534; and a logout routine 550. 

27 

28 Biller System Workflow 

29 79. Figures 6a, 6b, and 6c illustrate an exemplary biller system workflow in one 

30 embodiment of the system. When a user logs in 601 to the system using the 

30 



1 user ID of a biller, the system may display a biller system administration or 

2 "welcome" page 602. The system may display the user's name at the top in the 

3 form of a "Welcome 'Username" 1 message, for personalization. The system 

4 may display at a biller system administration page key biller statistics and a list 

5 of "action items" with current counts, amounts in local currency and links to the 

6 corresponding pages, as well as information about the basic functionality of the 

7 main topics. The system may also display at this page information provided by 

8 the administrative user regarding how to contact the administrative user. The 

9 current counts may include total invoices, closed invoices, paid invoices, unpaid 

10 invoices, and adjusted invoices. The system may provide a selection to the 

1 1 user for filtering and/or sorting the counts. The system may permit the biller 

12 system user to return to this page by clicking on a link that may be present on 

13 every page during system access. One area of the screen may contain 

14 navigation buttons grouped into categories, e.g., administration 603 (discussed 

15 further hereinbelow at "Biller System Administration"), invoices/payments 680, 

16 and reports 604. The system may expand these categories into subcategories 

17 that modify another portion of the screen. One area of the navigation frame 

18 may contain the user name (not the user ID) who is logged on. The system may 

19 allow the user to click on this link to modify his or her basic profile information. 

20 The system may provide other functionality, including a "help" button 650 for 

21 directing the user to a help section 651 and a "logout" button 652 for logging the 

22 current user out of the system. 

23 80. The system may allow the biller system user to select an option to edit the 

24 active user profile, wherein the system may direct the biller system user to a 

25 page displaying the organization name of the biller at the top, to establish the 

26 context of the current edit. The system may permit information to be 

27 maintained and edited at this page and may store the information as global 

28 information on the database, e.g., last name, first, middle, phone, fax, e-mail, e- 

29 mail2, password and confirmation. The system may require certain fields for 

30 user information, including last name, first name, e-mail and phone. The system 

31 may include this information in e-mails which may be sent through the system 
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1 and may also make this information available to biller and payer system 

2 administrators. 

3 81 . The system may permit a biller system user to select an option 605 to display 

4 invoices based on selected criteria and/or specify general search criteria for 

5 listing invoices. Depending on the selection, the system may direct the user to 

6 a "view options" page 606 for filtering and sorting. The system may provide a 

7 view options page 606 to allow the user control over the subset of data that will 

8 be displayed and the order in which the data will be presented. To further 

9 facilitate the presentation of invoices, the system may permit settings 

10 associated with a specific report to be automatically saved and used again the 

1 1 next time the user generates the report. Considering the time it may take to 

12 generate certain reports (e.g. lengthy reports), the system may also provide an 

13 option to bring this page up before running a report, to limit the scope and time. 

14 The view options page may consist of three exemplary areas: filter, sort and 

15 options. In the filter area, the system may provide the following exemplary 

16 choices: by date (past due, eligible for discount, due within xxx days); and by 

17 status (paid invoices, adjusted invoices, unpaid invoices, paid through another 

18 source); and by payer (all payer, specific payer); and by attribute range 

19 between xxx and yyy (none, invoice numbers, store / location, purchase orders, 

20 purchase request number, invoice issue dates, dollar amount, bill of lading 

21 numbers, receiving location zipcodes, invoice aging). The system may also 

22 provide the ability to search for invoice number, store or location number, 

23 routing number and P.O. number, by using wildcards. The system may provide 

24 a sort area to allow returned results to be sorted in ascending or descending 

25 order according to the following exemplary criteria: due date, invoice number, 

26 invoice date, purchase order number, net amount due, store or location 

27 number, and invoice aging. In one embodiment, the system may allow sorting 

28 criteria and order to be determined by a sort order combo box, which may 

29 default to ascending, and three sort criteria boxes, the first of which defaults to 

30 due date, while the rest default to no sort criteria (spaces). The system may 

31 provide an options area with the following exemplary choices: display all in one 
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Daae or show count (with the default beina all in one Daae). remember and use 
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previous settings, and show view options page before presentation. The 


3 




system may be adapted to store filter, sort, and options data as global 


4 




information on the database. 
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a page separated into two sections, with the header section containing non- 


12 




scrolling data and/or buttons and the body section that scrolls as necessary, 


13 




depending upon the width of the browser window and the number of invoices 


14 




being displayed. The header section may contain the following elements: 


15 


83. 


The user's selection criteria, i.e., All Invoices - Past due. 


16 


84. 


The display range text in the format of first - last of maximum, i.e., 1-20 of 200. 


17 


85. 


"Next 'n'" may cause the system to navigate the user to the next "n" invoices, 


18 




i.e., "Next 20". If the last "n" invoices are currently being displayed the system 


19 




may disable the "Next" button. 


20 


86. 


"Previous 'n'" may cause the system to navigate the user to the previous "n" 


21 




invoices, i.e., "Previous 20". If the first "n" invoices are currently being displayed 


22 




the system may disable the "Previous" button. 


23 


87. 


"AN" may cause the system to change the mode from displaying a page of 


24 




invoices to displaying all invoices, and the system may label the button "Page", 


25 




i.e., 1-200 of 200. If the "Page" button is selected, the system may display at 


26 




this page the first "n" invoices, and system may label the button "All". 


27 


88. 


"Back" may cause the system to return to the previous screen, step, or function. 


28 


89. 


"Search" may cause the system to perform a search in the current invoice list by 


29 




using the "Find" feature. The system may permit only the invoices currently 
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1 being displayed to be searched. The system may allow the user to type a string 

2 to search for before selecting the "Search" button. The system may search each 

3 invoice may for the specified string. If a match is found, the system may scroll 

4 the invoice record into view and select the text found. Selecting "Search" again 

5 may cause the system to find the next instance of the string. The system may 

6 permit wildcard searches. 

7 90. "Show Selected" may cause the system to display all invoices that have been 

8 manually checked. In the last column of the invoice list, the system may allow a 

9 user to select individual invoices. While the user remains on this page, the 

10 system may maintain in a list all invoices that are marked as selected. If the 

1 1 user switches the context of this view, the system may not remove any 

12 selection made by the user. Clicking on the "Show Selected" button may cause 

13 the system to display all the invoices the user has selected. The system may 

14 change this button to either "Page" or "All", depending on the state of the 

15 selection when this button was pressed. Selecting this button again may cause 

16 the system to return the invoice list to its previous mode. The system may 

17 display all selected invoices, even if they exceed the page limit. 

18 91 . "Close" 608 may cause the system to mark as closed all invoices that are 

19 selected. The system may display to the user a confirmation message before 

20 the invoices are closed, e.g., "You have selected 24 invoices to close. Are you 

21 sure you want to close these invoices?" The system may not permit closed 

22 invoices to appear in any active queries. The system may subject invoices that 

23 are marked as closed to host archiving and purging criteria. 

24 92. "Paid Through Another Source" may be provided by the system as an option for 

25 the biller system user to mark an invoice as closed by selecting desired invoices 

26 and clicking on the "Paid through another source" button. Once this occurs, the 

27 system may, for the invoices in question, update their audit trail to reflect that 

28 they were paid outside the system, and then change their status to "Closed". 

29 93. In the body section, the system may display all invoices in table format. The 

30 width of the table columns may be proportional to the width of the browser 
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1 window. If the browser window is narrowed, the system may decrease column 

2 widths appropriately and wrap text within each column, as necessary. If an 

3 invoice has adjustments, the system may highlight that line in color to indicate 

4 this fact. The system may link the invoice number field to the invoice detail 

5 page. The system may link the status field to the invoice history page, at which 

6 the system may display a full status history for the selected invoice. By default, 

7 the system may display the following exemplary columns: payer name, invoice 

8 number, due date, status, net amount due, amount to pay, P.O. number, P.O. 

9 requisition number, store number, and select. 

10 94. The system may permit the biller system user to select an option to display the 

1 1 details of a selected invoice, which may cause the system to direct the user to 

12 an invoice detail section 610. The system may use one or more predetermined, 

13 customizable and/or selectable template schema (which may be stored as 

14 global information on the database) to format the biller detail, and the system 

15 may provide a single biller multiple templates from which to select. The invoice 

16 detail page may contain various sections. One section may display summary 

17 information for the selected invoice, information about the biller, information 

18 about the particular invoice, and/or information about the payer. The system 

19 may provide selectable buttons for obtaining more information about the current 

20 invoice, e.g., items 611, messages 612, e-mail 613, status 614, shipping info 

21 615, discounts 616, and notes 617. The system may display line items that 

22 have been adjusted in a different color. Upon selection by a user of the items 

23 button 61 1 , the system may toggle the header view from showing a detailed 

24 header description to allowing the user to perform basic search operations on 

25 the details of this invoice. The items button 61 1 may cause the system to toggle 

26 to header. Clicking on the header button may cause the system to return to the 

27 previous view, thereby providing more space for viewing details on the current 

28 page, as follows. Another section may contain the line items that make up the 

29 invoice. The system may color code highlight line items that have been 

30 adjusted. Each line may have a clickable line number. Clicking a line item's 

31 number may cause the system to expand the line to show its detail. Clicking a 
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1 particular adjustment may cause the system to display a window with details 

2 about that specific adjustment. Another section may contain the invoice 

3 summary. For both the original amount billed and the amount to pay, the 

4 system may calculate and display the following: gross total invoice; time 

5 conditional discount; other discount / charge; a general adjustments link 

6 displays the general adjustment that was entered for this invoice (the system 

7 may only present this link if this invoice has a general adjustment; the system 

8 may show each general adjustment separately; and the system may permit 

9 general adjustments to be removed); sales tax; other tax; and net amount due. 

10 95. The system may, upon selection of the messages button 612, display a new 

1 1 browser window 622 allowing the biller system user to enter a new message for 

12 the payer associated with the current invoice. The system may permit new 

13 messages to be entered into a textbox and sent by pressing a "save" button. 

14 The system may provide a "cancel" button for discarding the current message 

15 and returning to the invoice detail page. The system may provide a discounts 

16 button 616 for opening a separate browser window 626 displaying discounts 

17 information for the current invoice, including, e.g., time conditional discount %; 

18 time conditional discount amount; time conditional discount date; invoice date; 

19 and unconditional discount or charge. The system may provide a shipping info 

20 button 615, which may cause the system to display additional shipping 

21 information for this invoice in a separate browser window 625, including, e.g., 

22 ship to location, date shipped, carrier, bill of lading number, terms, units, unit 

23 code, weight, volume, package dimensions, package contents, and notes. The 

24 system may provide a notes button 617 for opening a separate browser window 

25 627 containing a list of entered notes for this invoice. In the separate browser 

26 window, the system may permit the user to enter new notes into a new note 

27 textbox and save them by clicking an "add note" button. Clicking a "cancel" 

28 button may cause the system to return the user to the invoice detail page, 

29 discarding any new notes. The system may automatically log adjustment notes 

30 and biller disputes as notes for the current invoice. The system may provide an 

31 e-mail button 613 for opening a separate browser window 623 with a new e- 
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1 mail referencing the selected invoice. The system may permit the user to enter 

2 an e-mail message to selected users about the current invoice. The system 

3 may permit e-mail to be sent to the recipients that are picked from the recipients 

4 list, the contents of which may be based on the e-mail distribution list set up by 

5 the payer system administrator. The system may provide a status button 614 

6 for opening a separate browser window 624 displaying a page containing the 

7 status history for the selected invoice, including, e.g., date / time, user ID, and 

8 user name and status. The system may further provide adjustment buttons, 

9 e.g., general adjustment 618, quantity adjustment 619, price adjustment 620, 

10 and allowance 621 , at the invoice detail 610 section. The system may permit a 

11 general adjustment button 618 to be selected to open a separate browser 

12 window 628 containing general adjustment information for this invoice. This 

13 information may be read-only and may include the following exemplary items of 

14 information: adjustment amount, reason code, and notes. The system may 

15 permit a quantity adjustment button 619 to be selected for a specific invoice line 

16 item to open a separate browser window 629 containing quantity adjustment 

17 information for that line item. This information may be read only and may 

18 include the following exemplary items of information: adjustment quantity, 

19 reason code, and notes. The system may permit a price adjustment button 620 

20 to be selected for a specific invoice line item to open a separate browser 

21 window containing price adjustment information for that line item. This 

22 information may be read only and may include the following exemplary items of 

23 information: new price, reason code, and notes. The system may permit an 

24 allowance button 621 to be selected for a specific invoice line item to open a 

25 separate browser window 631 containing allowance information for that line 

26 item. This information may be read only and may include the following 

27 exemplary items of information: allowance amount, reason code, and notes. 
28 

29 96. The system may make other options available to the biller system user for 

30 selection, e.g. an items button for displaying the invoice details in item view. 

31 The system may, upon selection of such an button, remove the header from the 
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1 invoice details and all but the net amount due field of the footer, thereby 

2 allowing more screen space to be used for the presentation of invoices. The 

3 system may provide a search function for performing a search in the current 

4 invoice list. The system may permit only the invoices currently being displayed 

5 to be searched. The system may allow the user to type a string to search for 

6 before selecting the "Search" button. The system may search each invoice may 

7 for the specified string. If a match is found, the system may scroll the invoice 

8 record into view and select the text found. Selecting "Search" again may cause 

9 the system to find the next instance of the string. The system may permit 

10 wildcard searches. The system may provide clickable line numbers in the items 

11 view line, whereby upon clicking a line item's number, the system may expand 

12 the line to show its invoices, and clicking a particular adjustment may cause the 

13 system to bring up a window with details about that specific adjustment. 

14 97. The system may permit the biller system user to select an option 608 to retrieve 

15 all closed invoices in the system subject to the criteria set in the view options 

16 page and may provide the additional option of restoring selected invoices that 

17 have been closed into the current collection. The system may move invoices 

18 that have been checked to the open state when the user selects an "open" 

19 button. 

20 98. The system may permit the biller system user to select an option 632 to export 

21 files, i.e. to download data directly from the server, bypassing the need to have 

22 the data flow through a transmission to the biller system user. Selecting the 

23 export files option 632 may cause the system to direct the user to the invoice 

24 export section 633, from which the user may either edit export templates or 

25 export files. Upon selection of edit export templates, the system may allow the 

26 biller system user to edit the templates used in file export. An export templates 

27 listbox may show the present export templates while a template settings area 

28 may contain all the attributes and settings of the current selected template. 

29 Upon selection of a template from the export templates listbox, the system may 

30 populate the fields of the template settings area. In this area, the system may 

31 allow the biller system user to add, modify, or delete file export templates by 
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1 using a set of buttons or controls. The set of invoices to be exported may be 

2 based on the invoices that are being viewed at the time export is chosen. The 

3 system may permit the user to set that filter through the filter/sort page. The 

4 template settings area may contain the following exemplary controls (which the 

5 system may be adapted to store as global information on the database): fields 

6 and export order (may contain a listbox of the available invoice fields and an 

7 ordered listbox of fields marked for export with two buttons for moving fields 

8 between listboxes; up and down buttons may allow the field export order to be 

9 changed); and file formats (a listbox that allows the file format to be selected; if 

10 ASCII is chosen a delimiter section may be displayed and the user may need to 

11 select field and record delimiters). The system may provide a "set default" 

12 button for allowing the user to set the current template as the default template 

13 for the file export page. Upon selecting file export, the system may allow the 

14 biller system user to export invoices based on an export template. In the 

15 templates listbox, the system may show the present export templates while the 

16 export range may allow the user to select the date range criteria for including 

17 invoices in the export. In the templates list, the system may default to the 

18 template set as default from the edit export templates page; if no default 

19 template was set, the system may select the first entry in the listbox. An "export" 

20 button may cause the system to perform the file export, while a "cancel" button 

21 may cause the system to abort. The system may be adapted to export files in 

22 such exemplary formats as 810 for invoices, 820 for payments, XML, delimited 

23 files, and fixed-length PayBase™ compatible files. 

24 99. The system may permit the biller system user to select a reports option 604, 

25 which may cause the system to display subcategories that correspond to the 

26 available reports. Exemplary reports may include: paid invoices 641, total 

27 invoices 642, adjusted invoices 643, pending invoices 644, closed invoices 645, 

28 credit notes 646, and statistics 647. Other exemplary reports may include 

29 cashflow forecasting, aged outstanding invoice, returned items, modified invoice 

30 history, biller profile maintenance, payment history, and outstanding invoice 

31 status. The system may permit the user to select from among various reporting 
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1 options and/or filters 648 (which the system may be adapted to store as global 

2 information on the database), and the system may then generate a report 649 

3 for viewing and/or printing. 

4 Biller System Administration Workflow 

5 100. Figures 7a, 7b, and 7c illustrate an exemplary biller system administration 

6 workflow in one embodiment of the system. From the administration 700 

7 screen, the system may permit a biller system administrator to select from 

8 among functions including, e.g., edit biller profile 701 , archive/purge 710, edit 

9 banks 702, edit users 703, edit event e-mails 704, edit payers 705, adjustments 

10 706, edit export template 733, and password/profile change 735. 

11 101. Upon selection by the biller system administrator of the edit biller profile 701 

12 function, the system may redirect the biller system administrator to a biller 

13 profile section 707 for editing the biller's profile information. The system may 

14 permit company data to be entered and/or edited for the following exemplary 

15 fields (which the system may be adapted to store as global information on the 

16 database): name, address, city, state, zip, country, SIC code, TIN, and default 

17 template type. From the biller profile section 707, the system may permit the 

18 biller system administrator to select a function for editing logos and websites, 

19 which may cause the system to direct the administrator to a logo and website 

20 editing page 708, wherein the administrator may edit the biller's logos and 

21 available websites (which the system may be adapted to store as global 

22 information on the database). The system may display a list of billers, and the 

23 selection of a biller from the list may cause the system to populate the company 

24 information area with details about the current biller. For each biller, the system 

25 may permit a list of company logos and websites to be edited. The system may 

26 permit new logos to be made available to the system with an "add" button for 

27 uploading the logo file, and the system may likewise permit logos to be 

28 removed from the system with a "remove" button. The system may display a 

29 list of websites via a listbox containing the sites and a site details edit area. 

30 Selecting a website in the list may cause the system to populate the site details 
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1 section. The system may permit the URL, description, and type of website to 

2 be edited. The system may provide a delete button for removing a site from the 

3 list and a save button for saving the current website. The system may provide a 

4 new site button for emptying the edit area to allow a new site to be entered and 

5 saved. The system may provide selectable links for accessing the biller's 

6 enrollment page and biller profile page. The system may permit the 

7 administrator to select a template editing function, which may cause the system 

8 to direct the user to a template editing section 709. In the template editing 

9 section, the system may permit one or more predetermined, customizable 

10 and/or selectable template schema (which the system may be adapted to store 

1 1 as global information on the database) to be established and/or edited to format 

12 the biller detail, and the system may provide a single biller multiple templates 

13 from which to select. 

14 102. The system may permit the administrator to select an archive/purge 710 

15 function, wherein the system may direct the administrator to an archive/purge 

16 section 711. In this section, the system may permit the administrator to select 

17 functions for archiving (which the system may be adapted to store as global 

18 information on the database), including archiving data to a separate table, 

19 modifying options controlling when archiving is to occur (e.g. if an invoice stays 

20 in the "Presented" or "Viewed" state for more than X days; if an invoice stays in 

21 the "Paid" state for more than X days; and/or when an invoice is closed, it may 

22 be automatically archived); and reporting against archived data. The system 

23 may provide purging features (which the system may be adapted to store as 

24 global information on the database), including purging records only from the 

25 archive table(s); modifying options controlling when to purge (e.g. purge records 

26 after X days in archive; or manual purge). 

27 1 03. Upon selection by the biller system administrator of the edit banks 702 function, 

28 the system may redirect the biller system administrator to a biller bank editing 

29 section 712 for allowing the bank information associated with the biller to be 

30 edited. It is contemplated that a biller may have multiple banks with each bank 

31 having multiple bank accounts. An exemplary edit banks 712 section may be 
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1 separated into two sections. In the first section, the system may display the 

2 following exemplary fields (which the system may be adapted to store as global 

3 information on the database): name, address, city, state, zip code, country, 

4 country#, account # and RTN. The system may utilize a MOD9 or similar 

5 algorithm to verify valid routing numbers. In a second section, the system may 

6 display for the selected bank a "holidays" list-box populated with all bank 

7 holidays associated with this bank. Selecting an existing bank holiday from this 

8 list box may cause the system to delete the entry. Selecting a delete button may 

9 cause the system to delete the selected bank holiday. The system may provide 

10 combo-boxes for month, day and year selection. Selecting an add button may 

1 1 cause the system to add the selected date to the holiday list-box. If a bank is 

12 added with, or is caused to have no holidays through later modification, the 

13 system may display a warning to the user. 

14 104. The system may permit the administrator to select a "users" 703 function, 

15 wherein the system may direct the administrator to an edit user section 713. In 

16 this section, the system may permit the administrator to add, modify or delete 

17 users associated with the current biller. At this page, the system may display 

18 the name of the biller at the top to establish the context of the edit. The system 

19 may populate a list box with the selected biller system's user names. As the 

20 administrator clicks on each user, the system may display the user's information 

21 in a user information section. The system may permit the administrator to add a 

22 new user to the current biller by entering information into the user information 

23 section. The system may require that the combination of last name, middle 

24 initial and first name be unique. The system may permit modify and delete 

25 operations to be performed on the currently selected user. The system may 

26 provide a checkbox for temporarily deactivating a user. The system may 

27 maintain contact information (which the system may be adapted to store as 

28 global information on the database), including, e.g., last name, first, middle, 

29 phone, fax, e-mail, e-mail2, user ID, password, confirmation, language and 

30 privilege group. The system may require certain fields for user information, such 

31 as last name, first name, e-mail and phone. The system may provide a reset 



42 



1 password button for resetting the selected user's password to the default 

2 setting. The system may automatically send an e-mail to a new user after they 

3 have been added, telling the user how to connect and logon to the system. As 

4 described above with reference to the host user modifying privilege information, 

5 the system may similarly permit a biller system administrator to access a 

6 permissions section 715 for modifying permission/privilege information (which 

7 the system may be adapted to store as global information on the database). 

8 1 05. Upon selection by the biller system administrator of the event e-mails 704 

9 function, the system may direct the biller system administrator to an event e- 

10 mail section 714. In this section, the system may permit biller system users to 

11 be associated with specific system events, which associations the system may 

12 be adapted to store as global information on the database. Any time one of 

13 these specific events occurs, the system may generate an automatic e-mail and 

14 send it to the selected list of biller system users. For example, exemplary 

15 distribution list choices may include: invoices loaded successfully, invoices 

16 loaded unsuccessfully, invoice adjusted, payment authorized, payment 

17 canceled, payment completed, and payment notification. The system may 

18 display on this page a list-box that contains all biller system users currently in 

19 the selected distribution list and a list-box that contains all biller system users 

20 currently not in the selected distribution list. In one embodiment, the system 

21 may provide two buttons to allow users to be added or removed from the 

22 distribution list. The system may permit a default e-mail address to be set up 

23 for each event, e.g. the biller system administrator. The system may permit the 

24 user to remove this value and/or add to the list. The system may send an 

25 automatic e-mail to one or more biller system users when a payment is made. 

26 The system may send a summary of the payments made to each biller that has 

27 payments in the given payment run. The system may send to designated biller 

28 system users an e-mail with the following exemplary information: summary of 

29 payments made on today's date, payer name; payer number; total number of 

30 payments; and total amount of payments. 
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1 106. The system may further direct the biller system administrator, upon selection of 



2 the payers feature 705, to selections for performing tasks including options 716, 

3 adjustments 717, close invoices 718 and e-mail 719. Selecting the options 716 

4 task may direct the biller system administrator to a payer options 720 section, 

5 where options for a specific payer may be entered and/or edited. The system 

6 may display, at the payer options page, a list-box with all the payers related to 

7 the biller, with the system pre-selecting the most recently selected payer in this 

8 session by default. If no payer has previously been selected, then the system 

9 may not pre-select a payer in the list box. For the selected payer, the system 

10 may display the following exemplary payer options (which the system may be 

1 1 adapted to store as global information on the database): hide line items from 

12 invoice listing; allow payments; include signature; web site selection (which may 

13 be displayed using one or more multiple select listboxes); logo selection; payer 

14 ID; payment methods and account section (may cause the system to associate 

15 payment methods with biller account, and may include a set default button to 

16 establish the biller's default method and account); set default payment method 

17 and account; marketing message; legal text; and payer model. The system 

18 may provide a load default button to fill in all fields with the default entries. The 

19 system may provide a save default button to save the current entries as the 

20 default settings. Hitting the save button may cause the system to save the 

21 current payer's options, while hitting the cancel button may cause the system to 

22 discard any changes. Selecting the adjustments task may cause the system to 

23 direct the biller system administrator to an adjustments section 721 , where the 

24 system may permit the administrator to establish adjustments available to a 

25 specific payer and establish an e-mail notification list. The system may provide 

26 a checkbox for enabling and disabling disputes. If disputes are enabled, the 

27 system may make available for selection in a listbox the adjustments that the 

28 biller will allow the payer system users to make. The system, through the 

29 adjustments listbox, may enable the actual selection of adjustments available to 

30 the payer system users. The system may make all adjustments selected be 

31 available as long as the enable disputes checkbox is checked. The system 
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1 may also provide a checkbox for e-mailing one or more biller system users on 

2 adjustments. If this option is selected, the system may enable a mailing list 

3 button for sending automatic e-mails. The system may send to designated biller 

4 system users an e-mail for each adjustment made with the following exemplary 

5 information: "the following adjustment was made by payer name on today's 

6 date"; payer number; invoice number; adjustment type; adjustment amount; and 

7 adjustment reason. If there is no address set up to receive this e-mail, the 

8 system may send an e-mail message by default to the biller system 

9 administrator. The system may permit a mailing list function 722 may be 

10 accessed by the biller system administrator for modifying mailing list settings 

1 1 (which may be stored as global information on the database). The system may 

12 provide a close invoice function 718 for directing the biller system administrator 

13 to a close invoice section 723 to establish invoice-closing criteria for each 

14 payer. The system may only permit invoices with the status of "paid", 

15 "presented", or "viewed" to be closed. All other invoice states may indicate 

16 payer workflow is in progress, and the system may not permit invoices having 

17 such states to be closed. At the payer invoice close page 723, the system may 

18 display a list-box with all the payers related to the biller, with the system pre- 

19 selecting the most recently selected payer in this session by default. If no payer 

20 has previously been selected, then the system may not pre-select a payer from 

21 the list-box. For the selected payer, the system may present invoice closing 

22 criteria. The system may process criteria entered during the next nightly 

23 sweep. The system may mark as closed invoices that meet the closing criteria. 

24 Selecting the e-mail 719 task may cause the system to direct the biller system 

25 administrator to a payer e-mail 724 section for associating a list of biller system 

26 users with a specific payer (which associations the system may be adapted to 

27 store as global information on the database). At the payer e-mail page 724, the 

28 system may display a list-box with all the payers related to the biller. The 

29 system may pre-select the most recently selected payer in this session by 

30 default. If no payer has previously been selected, then the system may not pre- 

31 select a payer from the list-box. For the selected payer, the system may display 
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1 a page having a list-box that contains all biller system users currently related to 

2 the payer and a list-box that contains all biller system users currently unrelated 

3 to the payer. The system may provide two buttons to allow users to be added or 

4 removed from the related list. 

5 1 07. If the biller system administrator selects the adjustments 706 feature, the 

6 system may further direct the biller system administrator to selections for 

7 performing adjustment tasks including general 725, quantity 726, price 727, and 

8 line item allowance 728. When a new biller is created on the channel host, the 

9 system may give it a full set of the default adjustments for each of the four types 

10 (general, quantity, price, line item allowance). These system may permit these 

11 adjustments to be modified, added to, or deleted, allowing full customization by 

12 the biller. The system may provide a feature for restoring adjustments to the 

13 initial defaults. Selecting the general 725 button may cause the biller system 

14 administrator to be directed to a general adjustment codes page 729, wherein 

15 the system may permit global general adjustment codes to be edited. At this 

16 page 729, the system may display an adjustment list-box and an adjustment 

17 information area. The system may permit adjustments to be selected from the 

18 list-box to be edited or deleted. The system may permit new adjustments to be 

19 added by selecting an add button. The system may make adjustments entered 

20 here available to all of the biller's payers in the system. Exemplary associated 

21 fields may include: code and description. Selecting the quantity 726 button may 

22 cause the system to direct the biller system administrator to a quantity 

23 adjustment codes page 730, wherein the system may permit global quantity 

24 adjustment codes to be edited. At this page 730, the system may display an 

25 adjustment list-box and an adjustment information area. The system may permit 

26 adjustments to be selected from the list-box to be edited or deleted. The 

27 system may permit new adjustments to be added by selecting an add button. 

28 The system may make adjustments entered here available to all of the biller's 

29 payers in the system. Exemplary associated fields may include: code, 

30 description, threshold amount (which may only be active if "user defined" is not 

31 selected), and a "user defined" checkbox. Selecting the price 727 button may 
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1 cause the system to direct the biller system administrator to a price adjustment 

2 codes page 731 , wherein the system may permit global price adjustment codes 

3 to be edited. At this page 731 , the system may display an adjustment list-box 

4 and an adjustment information area. The system may permit adjustments to be 

5 selected from the list-box to be edited or deleted. The system may permit new 

6 adjustments to be added by selecting an add button. The system may make 

7 adjustments entered here available to all of the biller's payers in the system. 

8 Exemplary associated fields may include: code, description, threshold amount 

9 (which may only be active if "user defined" is not selected), and a "user defined" 

10 checkbox. Selecting the line item allowance button 728 may cause the system 

1 1 to direct the biller system administrator to a line item allowance adjustment 

12 codes page 732, wherein the system may permit global discount adjustment 

13 codes to be edited. At this page 732, the system may display an adjustment 

14 list-box and an adjustment information area. The system may permit 

15 adjustments to be selected from the list-box to be edited or deleted. The system 

16 may permit new adjustments to be added by selecting an add button. The 

17 system may make adjustments entered here available to all of the biller's 

18 payers in the system. Exemplary associated fields may include: code, 

19 description, amount (percentage), fixed or scaled, number of days, and a 

20 "penalty assessed" checkbox. 

21 108. The system may permit selection of an edit export templates 733 function for 

22 allowing the biller system administrator to edit the templates used in file export 

23 in an edit export template section 734. The system may display an export 

24 templates listbox showing the present export templates. In the template 

25 settings area, the system may display all the attributes and settings of the 

26 current selected template. Selecting a template from the export templates 

27 listbox may cause the system to populate the fields of the template settings 

28 area. In this area, the system may allow the biller system user to add, modify, or 

29 delete file export templates by using a set of buttons or controls. The set of 

30 invoices to be exported may be based on the invoices that are being viewed at 

31 the time export is chosen. The system may permit the user to set that filter 
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1 through the filter/sort page. The template settings area may contain the 

2 following exemplary controls (which the system may be adapted to store as 

3 global information on the database): fields and export order (may contain a 

4 listbox of the available invoice fields and an ordered listbox of fields marked for 

5 export with two buttons for moving fields between listboxes; via up and down 

6 buttons, the system may allow the field export order to be changed); and file 

7 formats (a listbox that allows the file format to be selected; if ASCII is chosen a 

8 delimiter section may be displayed and the system may require the user to 

9 select field and record delimiters). The system may provide a "set default" 

10 button for allowing the user to set the current template as the default template 

1 1 for the file export page. By selecting file export, the system may allow the biller 

12 system user to export invoices based on an export template. In the templates 

13 listbox, the system may show the present export templates, while, in the export 

14 range, the system may permit selection of the date range criteria for including 

15 invoices in the export. In the templates list, the system may default to the 

16 template set as default from the edit export templates page; if no default 

17 template was set, the system may pre-select the first entry in the listbox. The 

18 system may provide an "export" button for performing the file export and a 

19 "cancel" button for aborting. 

20 109. The system may provide a password/profile change button 735 for directing the 

21 biller system administrator to a password/profile change section 736 for 

22 changing password and/or profile information. 

23 Paver System Workflow 

24 110. Figures 8a, 8b, and 8c illustrate an exemplary payer system workflow in one 

25 embodiment of the system. When a user logs in 801 to the system using the 

26 user ID of a payer, the system may display a payer system administration or 

27 "welcome" page 802. The system may display the user's name at the top in the 

28 form of a "Welcome , Username" , message, for personalization. The system 

29 may display at a payer system administration page key payer statistics and a 

30 list of "action items" with current counts, amounts in local currency and links to 
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1 the corresponding pages, as well as information about the basic functionality of 

2 the main topics. The system may also display at this page information provided 

3 by the administrative user regarding how to contact the administrative user. 

4 The current counts may include invoices due today, invoices due tomorrow, 

5 invoices that will lose a discount today, invoices that will lose a discount 

6 tomorrow, invoices past due, invoices outstanding with adjustments, total 

7 invoices, verified invoices, initiated payments, authorized payments, and 

8 pending payments. The system may provide a selection to the user for filtering 

9 and/or sorting the counts. The system may display a biller list, which may 

10 include all billers that the payer has a relationship with in the system. The 

11 system may permit the payer system user to click on any biller to get a list of 

12 invoices from that biller. The system may permit the payer system user to 

13 return to this page by clicking on a link that may be present on every page 

14 during system access. One area of the screen may contain navigation buttons 

15 grouped into categories, e.g., invoices due today 803, invoices due tomorrow 

16 804, invoices that will lose a discount today 805, invoices that will lose a 

17 discount tomorrow 806, invoices past due 807, outstanding invoices with 

18 adjustments 808, total invoices 809, and verified invoices 810, all of which may 

19 link to an invoice list page 821 to display the desired invoices. Other navigation 

20 buttons may include initiated payments 81 1 (which may link to the initiate 

21 payment page), authorized payments 812 (which may link to the authorize 

22 payment page), pending payments 813 (which may link to the pending 

23 payments page), administration 814 (discussed further hereinbelow at "Payer 

24 System Administration"), invoices/payments 815, reports 816, and biller 

25 directory 817. The system may expand these categories into subcategories 

26 that modify another portion of the screen. One area of the navigation frame 

27 may contain the user name (not the user ID) who is logged on. The system 

28 may allow the user to click on this link to modify his or her basic profile 

29 information. The system may provide other functionality, including a "help" 

30 button 818 for directing the user to a help section 819 and a "logout" button 820 

31 for logging the current user out of the system. 
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1 111. The system may allow the payer system user to select an option to edit the 

2 active user profile, wherein the system may direct the payer system user may 

3 be directed to a page displaying the organization name of the payer at the top, 

4 to establish the context of the current edit. The system may permit information 

5 to be maintained and edited at this page and may store the information as 

6 global information on the database, e.g., last name, first, middle, phone, fax, e- 

7 mail, e-mail2, password and confirmation. The system may require certain fields 

8 for user information, including last name, first name, e-mail and phone. The 

9 system may include this information in e-mails which may be sent through the 

10 system and may also make this information available to biller and payer system 

1 1 administrators. 

12 112. If the payer system user selects invoices due today 803, invoices due tomorrow 

13 804, invoices that will lose a discount today 805, invoices that will lose a 

14 discount tomorrow 806, invoices past due 807, outstanding invoices with 

15 adjustments 808, total invoices 809, or verified invoices 810, the system may 

16 direct the payer system user to an invoice list page 821 for displaying invoices 

17 which meet the corresponding chosen parameters. At the invoice list page 821 , 

18 the system may display to the payer system user invoices based on selected 

19 criteria and/or allow the payer system user to specify general search criteria for 

20 listing invoices. Depending on the selection, the system may direct the user to 

21 a "view options" page 822 for filtering and sorting. At the view options page 

22 822, the system may allow the user control over the subset of data that will be 

23 displayed and the order in which the data will be presented. To further facilitate 

24 the presentation of invoices, the system may automatically save settings 

25 associated with a specific report (which may be stored as global information on 

26 the database) and allow them to be used again the next time the user 

27 generates the report. Considering the time it may take to generate certain 

28 reports (e.g. lengthy reports), the system may also provide an option to bring 

29 this page up before running a report, to limit the scope and time. The view 

30 options page may consist of three exemplary areas: extract, sort and options. 

31 In the extract area, the system may provide the following exemplary choices: by 
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1 date (past due, eligible for discount, due within xxx days); and by status (paid 

2 invoices, adjusted invoices, unpaid invoices, paid through another source); and 

3 by biller (all biller, specific biller); and by attribute range between xxx and yyy 

4 (none, invoice numbers, store / location, purchase orders, purchase request 

5 number, invoice issue dates, dollar amount, bill of lading numbers, receiving 

6 location zipcodes, invoice aging). The system may also provide the ability to 

7 search for invoice number, store or location number, routing number and P.O. 

8 number by using wildcards. The system may provide a sort area to allow 

9 returned results to be sorted in ascending or descending order according to the 

10 following exemplary criteria: due date, invoice number, invoice date, purchase 

11 order number, net amount due, store or location number, and invoice aging. In 

12 one embodiment, the system may determine sorting criteria and order by a sort 

13 order combo box, which may default to ascending, and three sort criteria boxes, 

14 the first of which may default to due date, while the rest may default to no sort 

15 criteria (spaces). The system may provide an options area with the following 

16 exemplary choices: define page size (for displaying invoices in a paging 

17 method), remember and use previous settings, and show view options page 

18 before presentation. The system may be adapted to store extract, sort, and 

19 options data as global information on the database. 

20 113. The system may allow a payer system user to select an option 821 to list 

21 invoices matching specified criteria. The system may display at this screen the 

22 filter/sort criteria that are in use for this display. The system may display 

23 invoices using a paging concept (i.e. 1 - 20 of 362). When displaying invoices, 

24 the system may remove any existing navigation area, so as to optimize the 

25 invoice display area. In one embodiment, the system may display a page 

26 separated into two sections, with the header section containing non-scrolling 

27 data and/or buttons and the body section that scrolls as necessary, depending 

28 upon the width of the browser window and the number of invoices being 

29 displayed. The header section may contain the following elements: 

30 1 14. The user's selection criteria, i.e., All Invoices - Past due. 
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1 115. The display range text in the format of first - last of maximum, i.e., 1-20 of 200. 

2 116. "Next ( n'" may cause the system to navigate the user to the next "n" invoices, 

3 i.e., "Next 20". If the last "n" invoices are currently being displayed the system 

4 may disable the "Next" button. 

5 117. "Previous 'n ,H may cause the system to navigate the user to the previous "n" 

6 invoices, i.e., "Previous 20". If the first "n" invoices are currently being displayed 

7 the system may disable the "Previous" button. 

8 118. "All" may cause the system to change the mode from displaying a page of 

9 invoices to displaying all invoices and the system may label the button "Page", 

10 i.e., 1-200 of 200. If the "Page" button is selected, the system may display at 

11 this page the first "n" invoices, and the system may label the button "All". 

12 119. "Back" may cause the system to return to the previous screen, step, or function. 

13 120. "Search" may cause the system to perform a search in the current invoice list by 

14 using the "Find" feature. The system may permit only the invoices currently 

15 being displayed to be searched. The system may allow the user to type a string 

16 to search for before selecting the "Search" button. The system may search each 

17 invoice for the specified string. If a match is found, the system may scroll the 

18 invoice record into view and select the text found. Selecting "Search" again may 

19 cause the system to find the next instance of the string. The system may permit 

20 wildcard searches. 

21 121 . "Show Selected" may cause the system to display all invoices that have been 

22 manually checked. In the last column of the invoice list, the system may allow a 

23 user to select individual invoices. While the user remains on this page, the 

24 system may maintain in a list all invoices that are marked as selected. If the 

25 user switches the context of this view, the system may not remove any 

26 selection made by the user. Clicking on the "Show Selected" button may cause 

27 the system to display all the invoices the user has selected. The system may 

28 change this button may change to either "Page" or "All", depending on the state 

29 of the selection when this button was pressed. Selecting this button again may 



52 



1 cause the system to return the invoice list to its previous mode. The system 

2 may display all Selected invoices, even if they exceed the page limit. 

3 122. "Paid Through Another Source" may be provided by the system as an option for 

4 the payer system user to mark an invoice as closed by selecting desired 

5 invoices and clicking on the "Paid through another source" button. Once this 

6 occurs, the system may, for the invoices in question, update their audit trail to 

7 reflect that they were paid outside the system, and then change their status to 

8 "Closed". 

9 1 23. In the body section, the system may display all invoices in table format. The 

10 width of the table columns may be proportional to the width of the browser 

1 1 window. If the browser window is narrowed, the system may decrease column 

12 widths appropriately and wrap text within each column, as necessary. If an 

13 invoice has adjustments, the system may highlight that line in color to indicate 

14 this fact. The system may link the invoice number field to the invoice detail 

15 page. The system may link the status field to the invoice history page, at which 

16 the system may display a full status history for the selected invoice. By default, 

17 the system may display the following exemplary columns: biller name (and/or 

18 logo(s)), invoice number, due date, status, net amount due, amount to pay, and 

19 select. The payer system administrator may optionally elect to display additional 

20 columns (e.g., P.O. number, P.O. requisition number, store number) by setting 

21 them in the payer profile (which may be stored as global information on the 

22 database). 

23 1 24. The system may permit the payer system user to select an option 823 to display 

24 the details of a selected invoice, which may cause the system to direct the user 

25 to an invoice detail section 610. The system may use one or more 

26 predetermined, customizable and/or selectable template schema to format the 

27 payer detail, and the system may provide a single payer multiple templates from 

28 which to select. The system may present detail using a selected language 

29 associated with the selected payer and/or user (which the system may be 

30 adapted to store as global information on the database). The invoice detail 
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1 page may contain various sections. One section may display summary 

2 information for the selected invoice, information about the payer, information 

3 about the particular invoice, and/or information about the biller. The system 

4 may provide selectable buttons for obtaining more information about the current 

5 invoice, e.g., items 831, messages 832, e-mail 833, status 834, shipping info 

6 835, discounts 836, and notes 837. The system may display line items that 

7 have been adjusted in a different color. Upon selection by a user of the items 

8 button 831 , the system may toggle the header view from showing a detailed 

9 header description to allowing the user to perform basic search operations on 

10 the details of this invoice. The items button 831 may cause the system to toggle 

11 to header. Clicking on the header button may cause the system to return to the 

12 previous view, thereby providing more space for viewing details on the current 

13 page, as follows. Another section may contain the line items that make up the 

14 invoice. The system may color code highlight line items that have been 

15 adjusted. Each line may have a clickable line number. Clicking a line item's 

16 number may cause the system to expand the line to show its detail. Clicking a 

17 particular adjustment may cause the system to display a window with details 

18 about that specific adjustment. Another section may contain the invoice 

19 summary. For both the original amount billed and the amount to pay, the 

20 system may calculate and display the following: gross total invoice; time 

21 conditional discount; other discount / charge; a general adjustments link (which 

22 may allow the general adjustment for the current invoice to be entered or 

23 edited); sales tax; other tax; and net amount due. 

24 125. The system may, upon selection of the messages button 832, display a new 

25 browser window 842 displaying any messages defined by the biller system 

26 administrator for this payer. Selection of the discounts button 834 may cause 

27 the system to open a separate browser window 846 displaying additional 

28 discount information for the current invoice, including, e.g., time conditional 

29 discount %; time conditional discount amount; time conditional discount date; 

30 invoice date; and unconditional discount or charge. Selection of the shipping 

31 info button 835 may cause the system to display additional shipping information 
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1 for this invoice in a separate browser window 845, including, e.g., ship to 

2 location, date shipped, carrier, bill of lading number, terms, units, unit code, 

3 weight, volume, package dimensions, package contents, and notes. In addition 

4 to the invoice specific shipping information, the system may list courier websites 

5 specified by the biller system administrator as links to the websites of the 

6 shipping companies, for shipment tracking or other purposes. Selection of the 

7 notes button 837 may cause the system to open a separate browser window 

8 847 containing a list of entered notes for this invoice. In the separate browser 

9 window, the system may allow the user to enter new notes into a new note 

10 textbox and save them by clicking an "add note" button. Clicking a "cancel" 

1 1 button may cause the system to return the user to the invoice detail page and 

12 discard any new notes. Selection of the e-mail button 833 may cause the 

13 system to open a separate browser window 843 with a new e-mail referencing 

14 the selected invoice. The system may allow the user to enter an e-mail 

15 message to selected users about the current invoice. The system may send e- 

16 mail to the recipients that are picked from the recipients list (which the system 

17 may be adapted to store as global information on the database), the contents of 

18 which may be based on the e-mail distribution list set up by the biller system 

19 administrator. Selection of the status button 834 may cause the system to open 

20 a separate browser window 844 displaying a page containing the status history 

21 for the selected invoice, including, e.g., date / time, user ID, and user name and 

22 status. The system may further provide adjustment buttons, e.g., general 

23 adjustment 838, quantity adjustment 839, price adjustment 840, and allowance 

24 841 , at the invoice detail 823 section. The system may permit a general 

25 adjustment button 838 to be selected to open a separate browser window 848 

26 containing general adjustment information for this invoice. This information may 

27 be read only and may include the following exemplary items of information: 

28 adjustment amount, reason code, and notes. The system may permit a quantity 

29 adjustment button 839 to be selected for a specific invoice line item, which may 

30 cause the system to open a separate browser window 849 containing quantity 

31 adjustment information for that line item. This information may be read only and 
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1 may include the following exemplary items of information: adjustment quantity, 

2 reason code, and notes. The system may permit a price adjustment button 840 

3 to be selected for a specific invoice line item, which may cause the system to 

4 open a separate browser window 850 containing price adjustment information 

5 for that line item. This information may include the following exemplary items of 

6 information: new price, reason code, and notes. The system may permit an 

7 allowance button 841 to be selected for a specific invoice line item, which may 

8 cause the system to open a separate browser window 851 containing allowance 

9 information for that line item. This information may be read only and may 

10 include the following exemplary items of information: allowance amount, reason 

1 1 code, and notes. 

12 1 26. The system may make other options available to the payer system user for 

13 selection, e.g. an items button for displaying the invoice details in item view. 

14 The system may, upon selection of such a button, remove the header from the 

15 invoice details, and all but the net amount due field of the footer, thereby 

16 allowing more screen space to be used for the presentation of invoices. The 

17 system may provide a search function for performing a search in the current 

18 invoice list. The system may permit only the invoices currently being displayed 

19 to be searched. The system may allow the user to type a string to search for 

20 before selecting the "Search" button. The system may search each invoice may 

21 for the specified string. If a match is found, the system may scroll the invoice 

22 record into view and select the text found. Selecting "Search" again may cause 

23 the system to find the next instance of the string. The system may permit 

24 wildcard searches. The system may provide clickable line numbers in the items 

25 view line, whereby upon clicking a line item's number, the system may expand 

26 the line to show its invoices, and clicking a particular adjustment may cause the 

27 system to bring up a window with details about that specific adjustment. 

28 127. The system may provide other selectable options, including a website button for 

29 opening a separate browser window containing links to biller-specific websites, 

30 and a biller info button for displaying a new browser window containing the biller 

31 information supplied for the current payer. 
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1 128. From the perspective of the payer system user, the system may identify an 

2 invoice as having one of the following exemplary states: presented, viewed (an 

3 invoice may be considered "viewed" when a invoice display query is built with 

4 the invoice included; the user does not necessarily need to actually see the 

5 invoice to have it considered viewed), verified (an invoice that is in this state 

6 may be rolled back to viewed given the user has the permission to verify), 

7 payment initiated, payment authorized, payment pending (an invoice in this 

8 state may be rolled back to verified given the user has the permission to 

9 authorize payment), paid, and closed. 

10 1 29. As illustrated in the payer invoice/payments workflow diagram of Figures 9a and 

1 1 9b, if the payer system user selects invoice/payments 81 5, the system may 

12 direct him or her to further select from among invoice/payment selections, which 

13 may include, e.g., review invoice 901 , initiate payment 902, approve/verify 

14 invoice 903, authorize payment 904, pending payment 905, payment history 

15 906, and file export 907. 

16 1 30. Selecting the review invoices 901 function may cause the system to direct the 

17 user to an invoice list 908, with appropriate links to invoice status 909, detail 

18 823, and sorting 910 pages. The invoice list 908, status 909, detail 823, and 

19 sorting 910 pages may be functionally identical to those described above with 

20 reference to Figure 8b, at ciphers 821-851 . 

21 131 . Selecting the approve/verify invoices 903 function may cause the system to 

22 direct the user to an approve/verify page 91 1 containing an invoice list, with 

23 appropriate links to invoice status 923, detail 823, and sorting 913 pages. The 

24 invoice list, status 923, detail 823, and sorting 913 pages may be functionally 

25 identical to those described above with reference to Figure 8b, at ciphers 821- 

26 851 . Via the invoice list shown, the system may permit the payer system user 

27 to view all invoices in the system that have not yet been approved for payment, 

28 subject to the criteria set in the view options page. The system may provide 

29 appropriate functionality to approve an individual invoice, approve a selection of 

30 invoices, or approve all invoices in the current extract. For any invoice in the 
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1 extracted set, the system may permit the user to view the corresponding invoice 

2 detail page 823 or the invoice status page 923. Invoices included on this page 

3 may indicate one of the following exemplary states: presented, viewed, or 

4 adjusted. The system may provide appropriate functionality to confirm approval 

5 of an individual invoice or group of invoices. The system may permit further 

6 selection of an "approve invoices" or "verify confirm" 914 page to permit the 

7 user to confirm the requested action. 

8 132. Selecting the initiate payment 902 function may cause the system to direct the 

9 user to an initiate payment page 915 containing an invoice list, with appropriate 

10 links to invoice status 909, detail 823, and sorting 910 pages. The invoice list, 

11 status 909, detail 823, and sorting 910 pages may be functionally identical to 

12 those described above with reference to Figure 8b, at ciphers 821-851 . Via the 

13 invoice list shown, the system may permit the payer system user to view all 

14 invoices in the system that have been approved for payment, subject to the 

15 criteria set in the view options page. The system ma provide appropriate 

16 functionality to initiate payment for an individual invoice, a selection of invoices, 

17 or all invoices in the current extract. For any invoice in the extracted set, the 

18 system may also permit the user to view the corresponding invoice detail page 

19 823 or the invoice status page 909. The system may display an "amount to 

20 pay" column, the amount shown being net of all applied credits and 

21 adjustments. The system may provide appropriate functionality to perform a 

22 cancel, which action may cause the system to roll back the status to viewed, 

23 detaching any applied credits if necessary. The system may permit the user to 

24 toggle between the discount date and the invoice due date. The system may 

25 set payment options to the default value established for the current biller / payer 

26 relationship. The system may page payments to accurately represent how the 

27 payment will be submitted. If the selection contains applied credit notes, the 

28 system may render each in a separate payment. The system may further permit 

29 the user to select a payment initiation selection page 91 6 to confirm the 

30 requested action, i.e. to confirm payment initiation of selected invoices in the 

31 system. 
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1 1 33. Selecting the authorize payment function 904 may cause the system to direct 

2 the user to an authorization page 917 containing an invoice list, with appropriate 

3 links to invoice status 912, detail 823, and sorting 913 pages. The invoice list, 

4 status 912, detail 823, and sorting 913 pages may be functionally identical to 

5 those described above with reference to Figure 8b, at ciphers 821-851 . Via the 

6 invoice list shown, the system may permit the payer system user to view all 

7 invoices in the system that have had payment initiated, subject to the criteria set 

8 in the view options page. The system may permit the user to click on any check 

9 number to view details for that payment group. The system may further permit 

10 the payer system user to select check boxes next to payments to select those 

1 1 payments, and to click on an "authorize" button to authorize those selected 

12 payments. The system may further permit the user to click on an "authorize all" 

13 button to authorize all payments listed. The payment method may be the 

14 payment option selected for this transaction, and the initiator may be the user 

15 name of the user who authorized the payment. The system may permit the 

16 authorize stage to be automatically bypassed if the payment amount is less 

17 than a pre-selected threshold amount. The system may further permit the user 

18 to select an authorize payment confirmation page 919 to confirm the requested 

19 action, i.e. to confirm payment authorization of selected invoices in the system. 

20 134. Selecting the pending payments 905 function may cause the system to direct 

21 the user to a pending payment page 918 containing an invoice list, with 

22 appropriate links to invoice status 912, detail 823, and sorting 913 pages. The 

23 invoice list, status 912, detail 823, and sorting 913 pages may be functionally 

24 identical to those described above with reference to Figure 8b, at ciphers 821- 

25 851 . Via the invoice list shown, the system may permit the payer system user 

26 to view all pending payments in the system subject to the criteria set in the view 

27 options page. The system may permit the user to click on any check number to 

28 view details for that payment group. The system may further permit the payer 

29 system user to select check boxes next to payments to select those payments, 

30 and to click on a "cancel" button to cancel the selected payments. The system 

31 may further permit the user to click on "cancel all payments" to cancel all 
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1 payments listed. Canceling a pending payment may cause the system to roll 

2 the transaction back to the "verified" invoice state. The system may further 

3 permit the user to select a cancellation confirmation page 920 to confirm the 

4 requested action, i.e. to confirm canceling pending payments for selected 

5 invoices in the system. 

6 1 35. Selecting the payment history 906 function may cause the system to direct the 

7 user to a payment history page 921 , wherein the user may view all paid 

8 invoices in the system, referencing the corresponding check number, subject to 

9 the criteria set in the view options page. The system may provide an invoice 

10 history page 922, whereby the system may display an invoice history line for 

11 each invoice that meets the view options criteria. Selecting an invoice number 

12 link may cause the system to display the corresponding invoice detail page 

13 (e.g., as shown and described with respect to cipher 823 of Figure 8b). The 

14 system may provide an invoice status link for displaying a corresponding 

15 invoice status page (e.g. as shown and described with respect to cipher 844 of 

16 Figure 8b). 

17 136. The system may permit the payer system user to select an export files function 

18 907, i.e., to download data directly from the server, bypassing the need to have 

19 the data flow through a transmission to the payer system user. Selecting the 

20 export files option 907 may cause the system to direct the user to the invoice 

21 export section 923, from which the user may either edit export templates or 

22 export files. Upon selection of edit export templates, the system may allow the 

23 payer system user to edit the templates used in file export. An export templates 

24 listbox may shows the present export templates while a template settings area 

25 may contain all the attributes and settings of the current selected template. 

26 Upon selection of a template from the export templates listbox, the system may 

27 populate the fields of the template settings area. In this area, the system may 

28 allow the payer system user to add, modify, or delete file export templates 

29 (which the system may be adapted to store as global information on the 

30 database) by using a set of buttons or controls. The set of invoices to be 

31 exported may be based on the invoices that are being viewed at the time export 
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1 is chosen. The system may permit the user to set that filter through the 

2 filter/sort page. The template settings area may contain the following 

3 exemplary controls (which the system may be adapted to store as global 

4 information on the database): document type, document status, include 

5 (headers and/or line items), fields and export order (may contain a listbox of the 

6 available invoice fields and an ordered listbox of fields marked for export with 

7 two buttons for moving fields between listboxes; up and down buttons may 

8 allow the field export order to be changed), file formats (a listbox that allows the 

9 file format to be selected; if ASCII is chosen, the system may display a 

10 delimiter section and require the user to select field and record delimiters; file 

11 formats may include X12 810, "XML 810", PayBase™, and CSV). The system 

12 may provide a "set default" button for allowing the user to set the current 

13 template as the default template for the file export page. Upon selecting file 

14 export, the system may allow the payer system user to export invoices based 

15 on an export template. N the templates listbox, the system may show the 

16 present export templates while the export range may allow the user to select 

17 the date range criteria for including invoices in the export. The system may 

18 provide a "today" checkbox, for aiding in setting the to bounding date to the 

19 current date. An "export" button may cause the system to perform the file 

20 export, while a "cancel" button may cause the system to abort. 

21 1 37. It is noted that the system may further permit a payer system user not only to 

22 view adjusted invoices from the invoice detail screen (e.g. cipher 823, as shown 

23 in Figure 8b and described above), but also to make adjustments to an invoice. 

24 In this scenario, from a user interface perspective, the system may allow the 

25 original amount to remain, but may change the "amount to pay" to "amount to 

26 adjust". At the bottom of the invoice, the system may add a new line that 

27 reflects the unapproved amount to pay, subject to any required approval. The 

28 system may also allow credit and debit notes to be entered by a payer system 

29 user, whereby credit notes may be entered by a user and/or handled by the 

30 system as invoices with a negative dollar amount, and debit notes entered by a 

31 user and/or handled by the system as invoices. Thus, the system may permit 
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1 credit requests to be entered in the same manner as adjustments are entered. 

2 If a credit request is issued, the system may send an e-mail to the distribution 

3 list for this event, referencing the invoice in question (i.e. invoice number, date, 

4 paying company, etc.), amount of credit requested, type of adjustment, 

5 adjustment code, and description of need for credit. After an invoice load, the 

6 system may execute a process that sets negative dollar invoices to a "verified" 

7 status, so that they will appear on the "initiate payment" list. The system may 

8 not roll back invoices with a "verified" status and a negative dollar amount to 

9 "presented" or "viewed" status. The system may make a report available to 

10 certain users listing all outstanding credit notes, including quantity and total 

11 dollar amount. 

12 1 38. As shown in the workflow diagrams of Figures 8 and 1 0, the system may permit 

13 the payer system user to select a reports option 81 6, which may cause the 

14 system to display subcategories that correspond to the available reports for 

15 selection. Exemplary reports may include: cashflow forecasting 1001 , payment 

16 history 1002, security administrator statistics 1003, payer profile 1004, invoice 

17 summary 1005, discount 1006, returned items 1007, outstanding invoice 

18 statistics 1008, and modified invoice summary 1009. The system may permit 

19 the user to select from among various reporting options and/or filters 1010 

20 (which the system may be adapted to store as global information on the 

21 database), and the system may then generate a report for viewing and/or 

22 printing at a report page 101 1 . 

23 1 39. As shown in the workflow diagram of Figures 8a, 8b, and 8c, the system may 

24 permit a payer system user to select a biller directory option for displaying a 

25 screen containing options which, when selected, cause the system to direct the 

26 user to pages for viewing biller websites and/or e-mail addresses 860 and a 

27 biller directory 861 (i.e. a list of available billers in the system). From the biller 

28 directory 861 , clicking on a biller's company name may cause the system to 

29 bring the user to a URL set by the biller system administrator. 



62 



1 Paver System Administration Workflow 

2 140. Figure 1 1 illustrates an exemplary payer system administration workflow in one 

3 embodiment of the system. From the administration 1 100 screen, the system 

4 may permit a payer system administrator to select from among functions 

5 including, e.g., edit payer profile 1101, edit banks 1102, edit users 1103, edit 

6 event e-mails 1 1 04, edit biller agreement 1 1 05, and password change 1 1 06. 

7 141 . Upon selection by the payer system administrator of the edit payer profile 1101 

8 function, the system may redirect the payer system administrator to a payer 

9 profile section 1 107 for editing the payer's profile information. The system may 

10 permit company data to be entered and/or edited for the following exemplary 

11 fields (which the system may be adapted to store as global information on the 

12 database): name, address, city, state, zip, country, SIC code, TIN, organization 

13 type, show invoice list columns, language for local country presentation, and 

14 currency for payment. The system may provide additional functionality for 

15 displaying an "instant payment" interface and a default settlement dates 

16 selector. At the instant payment interface, the system may permit the 

17 administrator to edit the company's instant payment terms that are used for 

18 payment of invoices in the system. The system may allow a payer system 

19 administrator to establish a threshold payment amount for instant payment. If an 

20 invoice comes in with a value less than the threshold amount, the system may 

21 be adapted to immediately initiate and authorize the invoice. When the 810 is 

22 loaded, if an invoice is below the threshold amount, the system may 

23 immediately create a payment, place it in the pending queue, and initiate an 

24 audit trail. Instant payment data (which the system may be adapted to store as 

25 global information on the database) may include the following exemplary fields: 

26 Instant payment (enabled/disabled), threshold amount, default account, default 

27 method of payment, and default settlement date (due date or discount date). 

28 The default settlement date may cause the system to provide additional 

29 functionality for the payer of having the settlement date by default be the due 

30 date to receive discounts. The system may provide the user the ability to 

31 change that date. 
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1 142. Upon selection by the payer system administrator of the edit banks 1 102 

2 function, the system may redirect the payer system administrator to a payer 

3 bank editing section 1 109 for allowing the bank information associated with the 

4 payer to be edited. It is contemplated that a payer may have multiple banks 

5 with each bank having multiple bank accounts. An exemplary edit banks 1 109 

6 section may be separated into three sections. In the first section, the system 

7 may display a list-box containing all the banks associated with the current 

8 payer. Selecting a bank from this list may cause the system to set the context 

9 for all other sections and fields of the page. For the selected bank, the system 

10 may display in a second section the following exemplary fields (which the 

1 1 system may be adapted to store as global information on the database): name, 

12 address, city, state, zip code, country, country#, account # and RTN. The 

13 system may use a MOD9 or similar algorithm to verify valid routing numbers. 

14 The system may provide a delete button, which may cause the system to 

15 display a confirmation message before deleting the selected bank. Selecting a 

16 modify button may cause the system to update the existing bank information 

17 with the modified data. Selecting an add button may cause the system to add 

18 the current bank information as a new bank. The system may require that the 

19 bank name and account # be unique. Pressing a "set default" button may cause 

20 the system to set the current bank as the default bank for making payments. In 

21 a third section, the system may display for the selected bank a "holidays" list- 

22 box populated with all bank holidays associated with this bank. Selecting an 

23 existing bank holiday from this list box, followed by the selection of a "delete" 

24 button, may cause the system to delete the selected bank holiday. The system 

25 may provide combo-boxes for month, day and year selection. Selecting an add 

26 button may cause the system to add the selected date to the holiday list-box. If 

27 a bank is added with, or is caused to have no holidays through later 

28 modification, the system may display a warning to the user. The system may 

29 be adapted to store holiday data as global information on the database. 

30 143. The system may permit a payer system administrator to select a "users" 1 103 

3 1 function, wherein the system may direct the administrator to an edit user section 
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1 1 1 10. In this section, the system may permit the administrator to add, modify or 

2 delete users associated with the current payer. At this page, the system may 

3 display the name of the payer at the top to establish the context of the edit. The 

4 system may populate a list box with the selected payer system's user names. 

5 As the administrator clicks on each user, the system may display the user's 

6 information in a user information section. The system may permit the 

7 administrator to add a new user to the current payer by entering information into 

8 the user information section. The system may require that the combination of 

9 last name, middle initial and first name be unique. The system may permit 

10 modify and delete operations to be performed on the currently selected user. 

1 1 The system may provide a checkbox for temporarily deactivating a user. 

12 Contact information (which the system may be adapted to store as global 

13 information on the database) may be maintained, including, e.g., last name, 

14 first, middle, phone, fax, e-mail, e-mail2, user ID, password and confirmation. 

15 The system may require certain fields for user information, such as last name, 

16 first name, e-mail and phone. The system may provide a reset password button 

17 for resetting the selected user's password to the default setting. The system 

18 may automatically send an e-mail to a new user after they have been added, 

19 telling the user that they have 24 hours to log in and change their password or 

20 the account will be disabled (e.g. where the password is set to the default of 

21 user's last name; the system may permit accounts to be re-enabled by a payer 

22 system administrator). The e-mail may also tell the user how to connect and 

23 logon to the system. The system may provide an "assigned billers" button for 

24 accessing the edit assigned billers page 1111, where the administrator may 

25 assign billers to the current user. At this page, the system may display the 

26 name of the payer and user at the top to establish the context of the edit. At 

27 this page, the system may display a list-box that contains all billers currently 

28 assigned to the current user and a list-box that contains all billers currently not 

29 assigned to the current user. The system may provide two buttons to allow 

30 billers to be added or removed from the assigned list. The system may provide 

31 a "permissions" button for permitting access to the permissions page 1112, 
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1 wherein the system may permit a user's permission scope to be narrowed to an 

2 organizational subset of the assigned biller. At this page, the system may allow 

3 the administrator to modify permissions associated with the current user. At this 

4 page, the system may display the name of the biller and user at the top to 

5 establish the context of the edit. At this page, the system may display a list of 

6 permissions available to the currently selected user. The system may determine 

7 the permissions available by the permissions available to the current 

8 administrator. Permissions (which the system may be adapted to store as 

9 global information on the database) may be inherited. The system may display 

10 in a list of permissions the organizational defined nodes. A single node may be 

11 assigned to the user. By default, a user may have full permissions. The system 

12 may permit the desired permission set to be selected for the user and then 

13 saved with a "save" button. The system may provide a "cancel" button for 

14 exiting and discarding all changes. The system may provide a number of pre- 

15 defined payer privilege profiles to simplify the security model. The system may 

16 permit the administrator user to choose one of these to give a new user a 

17 particular set of permissions. From there, the system may allow permissions for 

18 that user to be altered. Exemplary pre-defined payer privilege profiles (which 

19 may be stored as global information on the database) may include: 

20 144. Security Administrator: May have all payer profile and administration 

21 permissions, including the ability to set-up and delete ID's, bank accounts and 

22 the payer profile itself. The system may not allow this ID to be connected to any 

23 billers or any processing permissions. The system may permit this ID access to 

24 the security administration report only. The system may permit this ID only to be 

25 set-up by the system SuperUser. 

26 145. Receiving Supervisor: May be provided with a button called "adjust an invoice". 

27 With this new button, the system may permit a receiving administrator to be 

28 able to review an invoice and make changes. However, the system may restrict 

29 change permissions to quantity adjustments only. The system may link or map 

30 this type of ID to an individual biller or group of billers. 
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1 146. Purchasing Manager: May be provided with the buttons for list all invoices; 

2 approve invoices (keeping all adjustment capabilities intact); pending payments 

3 without the cancel payment privilege; invoice history and biller directories. The 

4 system may permit all these permissions to be filtered by biller if the ID were 

5 assigned to a particular biller or subset of billers. 

6 147. Payables Administrator: May have permissions for initiate payments, with one 

7 new feature, the ability to create a general invoice adjustment only prior to 

8 creating a payment order; pending payments without the cancel payment 

9 privilege and payment history. The system may permit all these buttons to be 

10 filtered by bank account and biller if the ID were assigned to a particular subset 

11 of bank accounts and/or billers. The system may assign this ID the following 

12 reports: return items. 

13 148. Payables Manager: May have permissions for authorize payments; pending 

14 payments with cancel payment permissions; payment history; invoice history; 

15 payer profile and biller directories. The system may allow this role to be filtered 

16 using dollar amount and may assign this ID the following reports: return items. 

17 149. Controller: May have permissions for list all invoices; pending payments without 

18 cancel payment permissions; payment history; and invoice history. The system 

19 may assign this ID the following reports: cashflow forecasting; outstanding 

20 invoices; discount management; adjusted invoice history and security 

21 administrator 

22 150. Cash Manager: May have permissions for pending payments without cancel 

23 payment permissions. The system may assign this ID the following reports: 

24 cashflow forecasting report. 

25 151. Payables Systems Administrator: May be responsible for managing the daily 

26 file export routine for both unpaid invoices and payments. 

27 1 52. Upon selection by the payer system administrator of the event e-mails 1 1 04 

28 function, the system may redirect the payer system administrator to an event e- 

29 mail section 1113. In this section, the system may permit a list of payer system 
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1 users to be associated with specific system events. Any time one of these 

2 specific events occurs, the system may generate an automatic e-mail and send 

3 it to the selected list of payer system users. For example, exemplary 

4 distribution list choices may include: invoices loaded successfully, invoices 

5 approved, payment initiated, payment authorized, payment canceled, and 

6 payment completed. The system may display at the this page a list-box that 

7 contains all payer system users currently in the selected distribution list and a 

8 list-box that contains all payer system users currently not in the selected 

9 distribution list. In one embodiment, the system may provide two buttons to 

10 allow users to be added or removed from the distribution list. The system may 

1 1 allow a default e-mail address to be set up for each event, e.g. the payer 

12 system administrator. 

13 1 53. Selecting edit biller agreement 1 1 05 may cause the system to direct the payer 

14 system administrator to an edit biller agreement page 1114, from which the 

15 payer system administrator may access such exemplary pages as biller 

16 organization 1115, options 1116, and biller e-mail 1117. 

17 1 54. The system may provide a biller organization page 1 1 1 5 to address the 

18 enterprise organizational model, the goal being to simulate the business 

19 structure of an enterprise so that the proper people can have access to and see 

20 the appropriate information. Although business organizations are hierarchical 

21 by definition, this structure may be too complex for the intended system 

22 implementation. Moreover, much of what makes up an organizational hierarchy 

23 is not passed as an attribute of an invoice transaction. Instead, what may be 

24 implemented supports the specificity of the hierarchical organization, while at 

25 the same time assuming no structure. For example, a biller organization might 

26 consist of company, department, region, division or store units. Assuming that 

27 these fields are populated within the invoice transactions of the system, the 

28 system may permit permission sets to be defined, each permission set being for 

29 assigning and establishing data access rights to specific users. Each 

30 permission set may contain one or more uniquely defined combinations. Three 

31 exemplary permission sets might be: Set #1 (Store #1, Store #2, Store #3); Set 
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1 #2 (Store #4, Store #5, Store #6); and Set #3 (Division #1 , Division #2). At the 

2 biller's organization page, the system may display a list-box containing all the 

3 billers related to the current payer. The system may pre-select by default the 

4 most recently selected biller in this session. If no biller has previously been 

5 selected, then the system may not pre-select any biller from the list-box. For 

6 the selected biller, the system may display the list of defined organizational 

7 elements or permission sets. The system may provide buttons to add, remove 

8 and modify an entry, and may further provide an edit control to allow editing of 

9 the name of the entry. The system may display a second list-box containing the 

10 specific data values that make up the organizational element for the selected 

1 1 biller. A data value may be made up of the field identifier and the field value. 

12 The system may provide a combo-box that allows the user to select the field 

13 identifier, and the system may provide an edit control to allow the user to enter 

14 the field value. The system may provide buttons to add, remove and modify an 

15 entry from this list. The system may be adapted to store biller organization data 

16 as global information on the database. 

17 1 55. Selecting the options function may cause the system to allow the payer system 

18 administrator to establish options for a specific bilier using a biller options page 

19 1 1 16. At the biller options page, the system may display a list-box containing 

20 all the billers related to the payer. The system may pre-select by default the 

21 most recently selected biller in this session. If no biller has previously been 

22 selected, the system may not pre-select any biller from the list-box. For the 

23 selected biller, the system may display the biller options. Exemplary biller 

24 ' options may include: payment methods and account. 

25 1 56. Selecting the biller e-mail function may cause the system to allow the payer 

26 system administrator to associate a list of payer system users with a specific 

27 biller using a biller e-mail page 1117. At the biller e-mail page, the system may 

28 display a list-box with all the billers related to the payer. The system may pre- 

29 select the most recently selected biller in this session by default. If no biller has 

30 previously been selected, the system may not pre-select any biller from the list- 

31 box. For the selected biller, the system may display at this page a list-box that 
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1 contains all payer system users currently related to the biller and a list-box that 

2 contains all payer system users currently unrelated to the biller. The system 

3 may provide two buttons to allow users to be added or removed from the 

4 related list. The system may be adapted to store the foregoing associations as 

5 global information on the database. 

6 157. The system may provide a password change button 1 106, for directing the 

7 payer system administrator to a password change section 1 120 for changing 

8 password information. 

9 Alternative Embodiments 

10 158. It will be appreciated by those skilled in the art that although the functional 

1 1 components of the exemplary embodiments of the system of the present 

12 invention described herein may be embodied as one or more distributed 

13 computer program processes, data structures, dictionaries or other stored data 

14 on one or more conventional general purpose computers (e.g. IBM-compatible, 

15 Apple Macintosh, and/or RISC microprocessor-based computers), mainframes, 

16 minicomputers, conventional telecommunications (e.g. modem, DSL, satellite 

17 and/or ISDN communications), memory storage means (e.g. RAM, ROM) and 

18 storage devices (e.g. computer-readable memory, disk array, direct access 

19 storage) networked together by conventional network hardware and software 

20 (e.g. LAN/WAN network backbone systems and/or Internet), other types of 

21 computers and network resources may be used without departing from the 

22 present invention. One or more networks discussed herein may be a local area 

23 network, wide area network, internet, intranet, extranet, proprietary network, 

24 virtual private network, a TCP/IP-based network, a wireless network, an e-mail 

25 based network of e-mail transmitters and receivers, a modem-based telephonic 

26 network, an interactive telephonic network accessible to users by telephone, or 

27 a combination of one or more of the foregoing. 

28 159. The invention as described herein may be embodied in a computer residing on 

29 a network transaction server system, and input/output access to the invention 

30 may comprise appropriate hardware and software (e.g. personal and/or 
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1 mainframe computers provisioned with Internet wide area network 

2 communications hardware and software (e.g. CQI-based, FTP, Netscape 

3 Navigator™ or Microsoft Internet Explorer™ HTML Internet browser software, 

4 and/or direct real-time TCP/IP interfaces accessing real-time TCP/IP sockets) 

5 for permitting human users to send and receive data, or to allow unattended 

6 execution of various operations of the invention, in real-time and/or batch-type 

7 transactions. Likewise, the system of the present invention may be a remote 

8 internet-based server accessible through conventional communications 

9 channels (e.g. conventional telecommunications, broadband communications, 

10 wireless communications) using conventional browser software (e.g. Netscape 

11 Navigator™ or Microsoft Internet Explorer™). Thus, the present invention may 

12 be appropriately adapted to include such communication functionality and 

13 internet browsing ability. Additionally, those skilled in the art will recognize that 

14 the various components of the server system of the present invention may be 

15 remote from one another, and may further comprise appropriate 

16 communications hardware/software and/or LAN/WAN hardware and/or software 

17 to accomplish the functionality herein described. 

18 160. Each of the functional components of the present invention may be embodied 

19 as one or more distributed computer program processes running on one or 

20 more conventional general purpose computers networked together by 

21 conventional networking hardware and software. Each of these functional 

22 components may be embodied by running distributed computer program 

23 processes (e.g., generated using "full-scale" relational database engines such 

24 as IBM DB2™, Microsoft SQL Server™, Sybase SQL Server™, Oracle 7.3™, 

25 or Oracle 8.0 ™ database managers, and/or a JDBC interface to link to such 

26 databases) on networked computer systems (e.g. comprising mainframe and/or 

27 symmetrically or massively parallel computing systems such as the IBM SB2™ 

28 or HP 9000 ™ computer systems) including appropriate mass storage, 

29 networking, and other hardware and software for permitting these functional 

30 components to achieve the stated function. These computer systems may be 

31 geographically distributed and connected together via appropriate wide- and 
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1 local-area network hardware and software. In one embodiment, program data 

2 may be made accessible to the user via standard SQL queries for analysis and 

3 reporting purposes. 

4 161. Primary elements of the invention may be server-based and may reside on 

5 hardware supporting an operating system such as Microsoft Windows 

6 NT/2000™ or UNIX. Clients may include a PC that supports Apple Macintosh 

7 ™, Microsoft Windows 95/98/NT/ME/2000™, a UNIX Motif workstation 

8 platform, or other computer capable of TCP/IP or other network-based 

9 interaction. In one embodiment, no software other than a web browser may be 

10 required on the client platform. 

11 162. Alternatively, the aforesaid functional components may be embodied by a 

12 plurality of separate computer processes (e.g. generated via dBase™, Xbase 

13 ™, MS Access™ or other "flat file" type database management systems or 

14 products) running on IBM-type, Intel Pentium™ or RISC microprocessor-based 

15 personal computers networked together via conventional networking hardware 

16 and software and including such other additional conventional hardware and 

17 software as may be necessary to permit these functional components to 

18 achieve the stated functionalities. In this alternative configuration, since such 

19 personal computers typically may be unable to run full-scale relational database 

20 engines of the types presented above, a non-relational flat file "table" (not 

21 shown) may be included in at least one of the networked personal computers to 

22 represent at least portions of data stored by a system according to the present 

23 invention. These personal computers may run the Unix, Microsoft Windows 

24 NT/2000 ™ or Windows 95/98/ME ™ operating systems. The aforesaid 

25 functional components of a system according to the present invention may also 

26 comprise a combination of the above two configurations (e.g. by computer 

27 program processes running on a combination of personal computers, RISC 

28 systems, mainframes, symmetric or parallel computer systems, and/or other 

29 appropriate hardware and software, networked together via appropriate wide- 

30 and local-area network hardware and software). 
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1 1 63. A system according to the present invention may also be part of a larger 

2 computerized financial transaction system comprising multi-database or multi- 

3 computer systems or "warehouses" wherein other data types, processing 

4 systems (e.g. transaction, financial, administrative, statistical, data extracting 

5 and auditing, data transmission/reception, and/or accounting support and 

6 service systems), and/or storage methodologies may be used in conjunction 

7 with those of the present invention to achieve an overall information 

8 management, processing, storage, search, statistical and retrieval solution for a 

9 particular lock box service provider, e-payment warehouses biller organization, 

10 financial institution, payment system, commercial bank, and/or for a cooperative 

1 1 or network of such systems. 

12 164. In one embodiment, source code may be written in an object-oriented 

13 programming language using relational databases. Such an embodiment may 

14 include the use of programming languages such as C++. Other programming 

15 languages which may be used in constructing a system according to the 

16 present invention include Java, HTML, Perl, UNIX shell scripting, assembly 

17 language, Fortran, Pascal, Visual Basic, and QuickBasic. Those skilled in the 

18 art will recognize that the present invention may be implemented in hardware, 

19 software, or a combination of hardware and software. 

20 1 65. The translation or mapping of EDI-type financial data, particularly of the X1 2, 

21 UN/EDIFACT, and NACHA formats, as discussed herein, is provided herein 

22 only as an example of transaction data capable of interacting with the invention 

23 and should not be construed so as to limit the use of the invention solely in such 

24 a setting. While the discussion herein presumes the use of the invention with 

25 respect to EDI, transactional, or financial data, it is anticipated that the invention 

26 may have utility in other contexts, as well. 

27 166. Payment options such as ACH debits, credit or procurement card payments, 

28 and/or paper checks may be provided. For ACH debits, a 24 hour settlement 

29 window may be required, in which case the payment must be sent to the 

30 receiving financial institution 24 hours prior to the settlement date specified by 
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1 the payer system user. If an ACH debit fails, an ACH return file may be sent 

2 from the financial institution, in which case the file is loaded and each 

3 transaction may be matched against invoices with the status of paid. When 

4 there is a match, the invoice in question may be reopened and rolled back to 

5 the status of "verified". Paper checks may be generated internally or by an 

6 external software module, wherein an output file in a format capable of being 

7 read by the external module may be generated. Payment by a payer system 

8 user using a credit or procurement card may also be effected, to be processed 

9 by internet or other means. In this scenario, additional security levels may be 

10 included, e.g., for initiating credit card payments (along with a dollar amount 

11 limit) and approving credit card payments, and such appropriate credit card 

12 payment processing functionality as may be appropriate may be included, as 

13 well. 

14 1 67. It should also be appreciated from the outset that one or more of the functional 

15 components may alternatively be constructed out of custom, dedicated 

16 electronic hardware and/or software, without departing from the present 

17 invention. Thus, the present invention is intended to cover all such alternatives, 

18 modifications, and equivalents as may be included within the spirit and broad 

19 scope of the invention as defined only by the hereinafter appended claims. 

20 168. It should be recognized by those skilled in the art that the present invention may 

21 have utility in contexts other than invoice payment, and that the parties to 

22 transactions handled by the invention may be entities other than payers and 

23 billers/payees in a vendor/vendee context. For example, the invention may be 

24 used in bank-to-bank transactions, bank-to-consumer transactions, consumer- 

25 to-consumer transactions, and any other financial transactional setting. 

26 169. Exemplary message definitions and corresponding business objects in one 

27 embodiment of the invention are listed in the table below along with a brief 

28 description of the functions performed by each, wherein exemplary business 

29 objects include AccountMgr, Adjustment, Agreement, Audit, ErrorHandler, 
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FileExport, FinlnstMgr, GetFinTrans, Getlnvoices, GetPayments, HolidayMgr, 
Invoicelnfo, LoginManager, MsgManager, and MsgUtils: 



Message 


Business 
Object 


Description 


Add Account 


AccountMgr 


Adds account to a given financial institution. 


DeleteAccount 


AccountMgr 


Delete account(s) from financial institution. 


GetAccountFinlnst 


AccountMgr 


Retrieves financial institution according to account ID. 


UpdateAccount 


AccountMgr 


Update a financial institution's account information. 


AssignBillerAdjustmentCodeList 


Adjustment 


Take in either a list of Adjustment Code Ids or a set of 

Assign BillerAdjustmentCode messages and add the whole list to the 

biller ID provided 


RpmnvpRillprAfjiu^tmpntnofipList 


Adjustment 


Take in either a list of Biller Adjustment Code Ids or a set of 
RemoveBillerAdjustmentCode messages and remove the whole list 
from the biller ID provided 


AssignPayerAdjustmentCodeList 


Adjustment 


Take in either a list of Adjustment Code Ids or a set of 
AssignPayerAdjustmentCode messages and add the whole list to the 
payer ID provided 


RemovePayerAdjustmentCodeList 


Adjustment 


Take in either a list of Payer Adjustment Code Ids or a set of 
RemovePayerAdjustmentCode messages and remove the whole list 
from the payer ID provided 


GetPayerAdjustmentCodeList 


Adjustment 


Return a PayerAdjustmentCodeList of all codes assigned to the payer 
for a given biller 


GetAdjustmentCodeList 


Adjustment 


Return an AdjustmentCodeList of all codes that are non-biller specific 


AddAdjustmentCode 


Adjustment 


Add a new adjustment code 


DeleteAdjustmentCode 


Adjustment 


Delete an existing adjustment code. Does not check to see if 
assigned anywhere else, does not update biller/payer adjustment code 
tables 


UpdateAdjustmentCode 


Adjustment 


Update an adjustment code specified by ID 


GetGeneralAdjustmentList 


Adjustment 


Get a GeneralAdjustmentList of all general adjustments for the given 
Invoice ID 


AddGeneralAdjustment 


Adjustment 


Add a general adjustment for a given invoice ID, update the 
agreement counters, and mark the invoice as having been adjusted 


UpdateGeneralAdjustment 


Adjustment 


Update a general adjustment for a given invoice ID, update the 
agreement counters, and mark the invoice as having been adjusted 


DeieteGeneralAdjustment 


Adjustment 


Delete a general adjustment for a given invoice ID, update the 
agreement counters, and check if there are still adjustments for this 
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invoice, else unmark the invoice as having been adjusted 


GetLineltemAdjustmentList 


Adjustment 


Get a LineltemAdjustmentList for a given LineltemDetail 


AddLineltemAdjustment 


Adjustment 


Add a new Line Item Adjustment to the given LineltemDetail by the ID 
provided and update the agreement counters and the 
grossAdjustedTotal amount and the adjusted flag on the invoice 


DeleteLineltemAdjustment 


Adjustment 


Delete a LineltemAdjustment from the given LineltemDetail by the ID 
provided and update the agreement counters and the 
grossAdjustedTotal amount and the adjusted flag on the invoice 


UpdateLineltemAdjustment 


Adjustment 


Update a LineltemAdjustment for the given LineltemDetail by the ID 
provided and update the agreement counters and the 
grossAdjustedTotal amount and the adjusted flag on the invoice 


AssignPayerAdjustmentCode 


Adjustment 


Assign an AdjustmentCode to the given payer Id while also providing 
the biller ID 


RemovePayerAdjustmentCode 


Adjustment 


Remove an adjustment code from a payer using the given 
PayerAdjustmentCode ID 


GetBillerAdjustmentCodeList 


Adjustment 


Get a BillerAdjustmentCodeList by the provided biller ID 


AssignBillerAdjustmentCode 


Adjustment 


Assign / Create an adjustment code for a biller. If an adjustment code 
is provided, it is assumed to be accurate and the relation is set up in 
the BillerAdjustmentCode table. If there is no adjustment code ID 
provided, the info for creating one can be provided for a biller-specific 
adjustment code and it will establish the relation in 
BillerAdjustmentCode and the entry in AdjustmentCode 


RemoveBillerAdiustmentCode 


Adjustment 


Remove an adjustment code from a biller If it is a hiller-SDecific code 
also remove it from the AdjustmentCode table 


UpdateBillerAdjustmentCode 


Adjustment 


Update the values in an existing BillerAdjustmentCode 


DisplayAdjCode 


Adjustment 


Get adjustment codes for any biller or agreement 


AddAgreement 


Agreement 


Add an agreement for a biller and payer ID combo to the system. 
Must have a biller ID, payer ID, customer number, and biller number 


DeleteAgreement 


Agreement 


Remove an agreement for a biller and a payer from the system 


UpdateAgreement 


Agreement 


Update the values in an agreement 


GetPayersForBillerNumber 


Agreement 


Get all of the Payers with agreements for this biller number 


GetNonPayersForBillerNumber 


Agreement 


Get all of the Payers who do not have agreements with this biller 
number 


GetPayersForBillerlD 


Agreement 


Get all of the Payers with agreements for this biller ID 


GetNonPayersForBillerlD 


Agreement 


Get all of the Payers who do not have agreements with this biller ID 


GetBillersForPayerlD 


Agreement 


Get all of the Billers with agreements for this payer ID 


GetNonBiliersForPayerlD 


Agreement 


Get all of the Billers who do not have agreements with this payer ID 


DeleteAgreementList 


Agreement 


Remove the agreements for the list of agreement IDs provided 


GetAgreementList 


Agreement 


Get agreement list based on any filter 


GetPayerAgreementList 


Agreement 


Returns InvoiceReviewUI Entity with payer and agreement info 
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GetBillprAareementLtet 


Anrppmpnt 


Rphirnc Inv/nippPpv/iPwl II Pntitv u/ith Killer anrl anroemont infn 
rvciuiiio ii i v(jiucr\t?vicvvui oiuiy wiiii uiiigi aiiu ayi cci iici il hiiu 


AddAuditMsgBulk 


Audit 


TakpQ a Itat nf audit mp^anp^ anrl inQPrta thpm intn thp rlataha^P 

Note audit messages can be of type: GENERAL, SYSTEM, 
SECURITY. 


AddAuditMsg 


Audit 


Adds an audit message to the database. Note audit messages can be 
of type: GENERAL, SYSTEM, SECURITY. 


DeleteAuditMsg 


Audit 


Deletes an audit message from the database. 


GetAuditMsgList 


Audit 


Gets a list of audit messages from the database 


PfKtFrmrM^n 

I UOILI 1 wl IVIOM 


t_i 1 \Jl rial IUICI 


Pnct an prrnr meccanp \/ia thp ^plpotnr 
ruoi aii tsiiui nicooayc via tilt? ocicoiui. 


Pn^tFrrnr 


a iu( rial luiei 


Poctc an orr/"\r moccsno Hiror>tlw \A/ith/"*iit a ^all thrvMinh tha Qolo/"*tAr 
rUolo all ClIUI IMcooayt; UllcOuy, WIUIUUl a udll UHUUyil Ule OtJItJOLUf . 

The function uses ADO to access the database, instead of the 
standard engine calls. 


ExportUnapprovedlnvoicesToCSVFile 


FileExport 


Exports a list of unapproved invoices to character delimited file format. 


ExportUnauthorizedPaymentsToCSVFile 


FileExport 


Exports a list of unauthorized payments to a character delimited file 
format. 


ExportUnapprovedlnvoicesToXMLFile 


FileExport 


Exports a list of unapproved invoices to an XML file. 


ExportUnauthorizedPaymentsToXMLFile 


FileExport 


Exports a list of unauthorized payments to an XML file. 


AddFinlnst 


FinlnstMgr 


Adds a financial institution to the system. 


DeleteFinlnst 


FinlnstMgr 


Deletes a financial institution from the system. 


UpdateFinlnst 


FinlnstMgr 


Updates a financial institution. 


GetFinlnstList 


FinlnstMgr 


Retrieves a financial institution list for a given biller, or payer. 


DisplayAccount 


FinlnstMgr 


Get account lists for any filter 


DisplayBankList 


FinlnstMgr 


Get current bank info 


GetFinTranList 


GetFinTrans 


Get a FinTranList. Can either provide where and orderby info or a list 
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of FinTran Ids 


GetFinTran 


GetFinTrans 


Get a specfic FinTran by ID 


GetFinTranReviewList 


GetFinTrans 


A light Ul based method for getting FinTrans with a single invoice and 
payment 


GetlnvoiceList 


Getlnvoices 


Get an InvoiceList. Can either provide where and orderby info or a list 
of Invoice Ids 


GetlnvoicesForPayment 


Getlnvoices 


Get an InvoiceReviewUIList for a given paymentld 


GetlnvoiceHistory 


Getlnvoices 


Get a FinTranList for payments which were batched more than 60 
days ago, then display the invoices for them 


GetlnvoiceReviewList 


Getlnvoices 


Get a InvoiceReviewUIList. Can either provide where and orderby info 
or a list of Invoice Ids 


Getlnvoice 


Getlnvoices 


Get a specific Invoice by ID 


GetPaymentReviewList 


GetPayments 


Get a PaymentReviewUIList. Can either provide where and orderby 
info or a list of Payment Ids 


GetPaymentList 


GetPayments 


Get a FinTranList. Can either provide where and orderby info or a list 
of Payment IDs. Used FinTranList so Xpath filter could work against 
any criteria under it 


GetPaymentHistory 


GetPayments 


Get a FinTranList for payments which were batched more than 60 
days ago, then display the payments for them 


Add Holiday 


HolidayMgr 


Adds a holiday to a specified financial institution. 


UpdateHoliday 


HolidayMgr 


Updates a holiday entry in the database with new information. 


DeleteHoliday 


HolidayMgr 


Removes a holiday from a financial institution. 


GetHolidayList 


HolidayMgr 


Gets a list of holidays for a given financial institution. 


ValidateSettlementDate2 


HolidayMgr 


This function can be called directly from any component without the 
Selector. It takes a date, and a financial institution ID. If the date is a 
holiday or a weekend then the next possible workday is returned. 
Otherwise the original date is returned in string form. 


ValidateSettlementDate 


HolidayMgr 


If the date is a holiday or a weekend then the next possible workday is 
returned. Otherwise the original date is returned in the XML message 
parameter. 


GetlnvoiceCountsForUser 


Invoicelnfo 


Get invoice counts for the following: 

Invoices due today, Invoices due tomorrow, Invoices that lose 
discount today, Invoices that lose discount tomorrow, and Invoices 
that are past due. Uses the stored proc Getlnvoice Info and passes 
back the counts and the Xpath to select the data set which is placed in 
the payer front screen hyperlinks for the counts 


GetlnvoiceStatusList 


Invoicelnfo 


Get the InvoiceStatus change entries for a given Invoice ID 


AddlnvoiceStatus 


Invoicelnfo 


Add a new InvoiceStatus record for an invoice ID 
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Login 


1 nninMananpr 

LwUII 1 1 V (G2 1 laud 


1 nnc a iiQpr intn thp ^v^tpm na^^inn it a iiqpt nsmp and n^Q<i\A/nrH 

The user will be authenticated against his/her domain credentials as 
well as the NetTransact database information. 


Logoff 


LoginManager 


User logs off according to his/her session ID. A session ID is needed 
as part of the formal message command. 


Dispatch Msg 


MsgManager 


Dispatches a message to the selector. If session information is 
needed, then the parameters in the original message body are filled in. 


GetPayerBillerAdjustmentCodesWithAssign 
ed 


MsgUtils 


Get a BillerAdjustmentCodeList for the biller supplied, match the 
PayerAdjustmentCodes for the payer supplied to the 
BillerAdjustmentCodes and set the assigned attribute on the 
BillerAdjustmentCodeList where there is a match. Gives a single list 
for what biller adjustment codes are available and which have been 
assigned to the payer 


GetPayerAdjustmentCodesWithAssigned 


MsgUtils 


Get all AdjustmentCodes in an AdjustmentCodeList and match the 
PayerAdjustmentCodes for the payer supplied to the 
AdjustmentCodes and set the assigned attribute on the 
AdjustmentCodeList where there is a match. Gives a single list for 
what adjustment codes are available and which have been assigned 
to the payer 


GetBilierAdjustmentCodesWithAssigned 


MsgUtils 


Get all AdjustmentCodes in an AdjustmentCodeList and match the 
BillerAdjustmentCodes for the biller supplied to the AdjustmentCodes 
and set the assigned attribute on the AdjustmentCodeList where there 
is a match. Gives a single list for what adjustment codes are available 
and which have been assigned to the biller 
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